38 questions tagged with "General"

During phone screens, especially for Senior iOS roles, I’ve been tested on my understanding of provisioning profiles, development and distribution certificates, App Store Connect, and everything related to managing an iOS release.

As part of that line of questioning, I’ve often been asked to clarify the difference between the App ID and the Bundle ID.

The Bundle ID is simply an identifier written in reverse DNS format that uniquely identifies a single app.

The following example should look pretty familiar to you:

com.AryamanSharda.WalkingRoutes

The Bundle ID can only contain alphanumeric characters and a period.

Since the Bundle ID is specific to an application, it’s useful in helping the system distinguish between the installation of a new app or an app update. Also, because a single Xcode project can have multiple targets and therefore output multiple apps, the Bundle ID lets you uniquely identify each of your project’s targets.

The App ID is a two-part string used to identify one or more apps from a single development team. It consists of an Apple issued Team ID and your application’s Bundle ID. Additionally, the App ID is used to specify what App Services (Game Center, iCloud, In-App Purchases, Push Notifications, etc.) are available to your application.

The Team ID is created when you open a new Developer Account with Apple and is unique to your specific development team.

Here’s an App ID that matches a specific application:

Explicit App ID:A123456789.com.AryamanSharda.WalkingRoutes

We can also have the App ID match multiple applications from the same development team:

Wildcard App ID:A123456789.com.AryamanSharda.*

Every class requires a designated initializer as it’s responsible for initializing stored properties and calling the superclass’s init().

A convenience initializer can be thought of as a wrapper around the designated initializer. They allow you to create a simpler initialization option for your class that either provides defaults for certain initialization parameters or helps transform some input into the exact format the designated initializer needs.

In Swift, we can create a convenience initializer by placing the keyword convenience before the init. A class can have any number of convenience initializers. These initializers can even call other convenience initializers in turn, but eventually they’ll need to call the designated initializer:

class Money: NSObject {
    let value: Int
    let currencyCode: String

    init(value: Int, currencyCode: String) {
        self.value = value
        self.currencyCode = currencyCode
        super.init()
    }

    convenience init?(value: String, currencyCode:String) {
        guard let numericValue =Int(value) else {
            return nil
        }

        self.init(value: numericValue, currencyCode:currencyCode)
    }
}

In this example, the designated initializer expects value to be an Int. So, we can create a convenience initializer that helps us handle scenarios when we might have a String as input instead.

Notice that the convenience initializer is eventually calling the designated initializer.

The system uses the stack to store anything on the immediate thread of execution; it is tightly managed and optimized by the CPU.

When a function creates a variable, the stack will store that variable for the lifetime of the function call. Since the stack is so strictly organized, it’s very efficient and fast.

The system uses the heap to store reference types. The heap is a large pool of memory from which the system can request and dynamically allocate blocks of memory.

The lifetime of the items on the heap are flexible and dynamic as the heap doesn’t automatically destroy its data like the stack does. Instead, explicit allocation and deallocation calls are needed.

This makes creating and removing data from the heap a slower process compared to creating and removing data from the stack.

Prior to iOS 13, the AppDelegate was the main entrypoint for your application. This is where you would typically start the configuration of your third-party dependencies and establish the starting conditions for your application.

However, as of iOS 13, some of the responsibilities of the AppDelegate have been transitioned to the SceneDelegate. This change is due to the new multi-window support feature introduced with iPadOS.

With multi-window support, we’ll still have one application, but it can have multiple windows (e.g. imagine Google Chrome or Safari). So, we’ll need a separate object whose sole purpose is to manage the window(s) of the application.

The AppDelegate will continue to be responsible forthe application lifecycle and initial setup, but the SceneDelegate will now be responsible forwhat is shown on the screen.

As part of this transition, the SceneDelegate will enable us to create multiple instances of our app’s UI all backed by the same AppDelegate. This new multi-window support also means that each of these instances will appear as separate views in iOS’s application switcher.

Moreover, each window is meant to work independently from one another, so now screens can independently move from the foreground to the background or vice-versa.

AppDelegate’s responsibilities are otherwise unchanged.It will still be responsible for setting up any data needed for the duration of the application, configuring your app’s scenes, registering for external services like push notifications, and managing the application’s lifecycle.

In a nutshell, the SceneDelegate manages the iOS app’sUI lifecycle methods whereas the AppDelegate only handles the iOS app’s applicationlifecycle methods.

There’s no right or wrong answer here as the question is inherently subjective, but it’s a great opportunity for you to demonstrate that you understand the challenges and limitations with each approach (.xib vs .storyboard vs programmatically).

Storyboards Storyboards are a great way to quickly build out new designs and are useful in encapsulating a particular user flow. By keeping all of the views relevant to an experience in your app in the same storyboard, it makes it easier to get a high-level overview of the applications’ functionality and intended user experience. Storyboards can also make navigating to and from other UIViewControllers very easy via segues.

However, storyboards can be difficult to work with on a team as they’re prone to merge conflicts, long loading times, and responsiveness often suffers as the storyboard increases in size.

XIBs While xibs and storyboards share a lot of similarities, they trade the storyboard’s navigation behavior for increased reusability. Since a xib is specific to one view, there’s no provision of establishing segues from one view to the next. You’ll typically use a xib when you have a single custom component that you want to re-use in multiple locations throughout the app.

Both storyboards and xibs make design changes very cumbersome to implement. For example, if you wanted to change the application’s default font, colors, icons, or some other application-wide change needs to be made, you’d have to go into each storyboard and xib and manually update each view.

There are ways to mitigate this, but the “source of truth” gets a bit lost. Since you’ll often apply additional styling programmatically (like shadows and rounded corners), a developer now needs to check multiple locations to get a full picture of the view’s complete implementation and expected appearance. Last but not least, searching for constraints, custom styling, subviews, images, fonts, etc. is much more difficult on storyboards and xibs than on a view defined programmatically.

Programmatically

While this option can be tedious and is often initially slower than the other options, it allows for greater control, improved searchability, and more reuse.

Any application-wide UI change can be made easily, merge conflicts are easier to manage, there’s a single source of truth, and views created programmatically can be more easily tested.

In practice, you’ll likely find that there’s rarely ever one right approach. Often, production projects will have a mix of all three methods depending on how much reuse and development speed influences the decision making.

Every iOS interview I've done has dealt with UITableViews in some capacity. Most often, it will involve hitting some API and showing the response in a UITableView like we did in Assessment #1.

As you prepare for your interviews, you should aim to be able to create a UITableView with custom UITableViewCell swithout referring to any documentation.Ideally, this set up process should become second nature to you.

Since this topic will be a constant in all of your interviews, knowing precisely what functions are necessary and what their respective inputs, outputs, and method signatures are is crucial.

Here are the only required UITableViewDataSource methods:

// Return the number of rows for the table.
override func tableView(_ tableView: UITableView,
    numberOfRowsInSection section: Int) -> Int {
    return 0
}

// Provide a cell object for each row.
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    // Fetch a cell of the appropriate type.
    let cell = tableView.dequeueReusableCell( withIdentifier:"CellIdentifier", for: indexPath)

    // Configure the cell's contents.
    cell.textLabel!.text = "Cell text"
    return cell
}

In Swift, value types can contain reference types and reference types can contain value types.

In this case, the result is simply the creation of a value type with a property that has reference semantics. In other words, the reference type behaves like it always does.

Any changes made to the reference type will also be reflected in the property within the value type.

In the following example, theUserobject is a referencetype. You’ll see that changes made to the reference type modify the property in thestruct.

class User {
    var name: String
    var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

struct Article {
    var author: User
    var id: Int
}

let user = User(name: "Aryaman", age: 26 )
let article = Article(author: user, id: 123 )

// Output: Aryaman
print(article.author.name)

user.name = "Aryaman Sharda"

// Output: Aryaman Sharda
print(article.author.name)

Typically, you’ll want to use astructif any of thefollowing conditions apply:

• Use astructwhen encapsulating simple data types
• When you need thread safety asstructsare passed-by-value
• You want pass-by-value semantics
• When the properties defined inside the entity are mostly value types
• You don’t need inheritance
• You don’t need mutability
• When you want automatic memberwise initializers

Apple’s recommendation is to start with astructandtransition to aclassonly if you need inheritance or pass-by-reference semantics. However, if your entity is storing a lot of data then it may make sense to use aclassso you’re only incurringthe memory cost once.