Using Xcode Organizer

Building directly to local devices lets you get farther in testing and app development than building to a simulator. Eventually, you’ll want to build for a broader set of devices within your organization. Then perhaps for external testers and finally for the App Store.

To fully follow along for the rest of this lesson, you need to join the Apple Developer Program. However, there’s still valuable information if you’re not planning on joining now or ever.

Joining the Apple Developer Program gets you two main benefits: the ability to distribute test versions of your app through TestFlight and the ability to sell your app in Apple’s App Store once it’s passed Apple’s review process.

You can purchase a membership in the developer program, or someone who’s already a member can invite you to their team. If you purchase your own, you’ll be able to invite others.

If you’re part of a team, you might have read-only access to App Store Connect, TestFlight and other parts of your team’s developer account, but you’ll be able to use the team’s signing certificates and app IDs. So you can distribute anything you build and sign with the team’s certificates to a broader audience than just your own devices.

The image above shows that this developer can sign apps with their personal or team certificates. This developer can build any of the team’s apps and distribute new versions. Some teams will require each developer to create a new Apple ID when they join; others will let a developer use an existing Apple ID. Xcode will show all of the developer certificates installed on the Mac. In the image above, Xcode shows the personal team and the one business team for this user as Team options on the Signing page.

Organizer

The Organizer lets developers prepare an app for distribution and get data about how their app performs in the real world. It’s also where Xcode stores app archives. When you set up a new phone, one of the prompts is for sharing data with developers. If you agree to that, the data will filter down to the developers in the Organizer.

One of the more essential things that filters back to developers is crash reports. Even though an .ipa distributed through the App Store is optimized and stripped of debugging symbols, Xcode creates a dSYM file that returns the symbols so that crash reports are readable. A dSYM file is uploaded with the executable for all App Store and TestFlight builds.

In the image above, the developer can see some information about the crash. The report shows the kind of device, what version of iOS it was using, and which App Store build. If the crash happens to many devices, the graph showing a 0 in this report would show the total number of crashes and give some information about how many per day.

The stack trace should look familiar from the lesson on debugging. Remember, the blue person icons denote your code in a stack trace. So the developer can see exactly which method caused the crash.

Notice at the very top that there is a + 536. This is the offset from the beginning of the method. If the developer had the source code on this machine and clicked the Open in Project… button, Xcode would open to the exact line that caused the crash.

The other information that the App Store collects is accessed on the left pane. A slightly maddening thing about this data is that Apple doesn’t report it unless there’s a lot of it. So, if you’re working with an app that isn’t widely used, you won’t see any statistics. You’ll need to use a service like Firebase or Visual Studio’s App Center to collect that information.

To add an app to the Organizer, you’ll make an archive of it. In the build destinations, instead of choosing a particular simulator or device, you’ll choose a generic build destination.

You can use a personal team to put the app in the Archive, but that’s not very useful. Signing the app with a team that’s part of the Developer Program will let you distribute it to devices other than the ones you’ve connected to Xcode.

Then, instead of clicking the build and run button, use the Product ▸ Archive menu item. Archiving your build builds it differently than for debugging. For one thing, Xcode strips out unneeded symbols. It’ll also use a different optimization strategy to ensure your app executable is compact. In the Build Settings window of the project settings, you can see every setting that’s different for Release/Archive and Debug builds.

The image above shows that when you make a debug build, it only builds for the CPU architecture associated with your build destination device. But when you make a release build, it’ll build for all the CPU architectures supported by the minimum version and Supported Destinations settings. For every build setting that differs between Release and Debug, you’ll see a little toggle arrow to the left you can open to see the values.

Once the build is done, the app appears in the Organizer.

A quick note about build numbers: the number inside the parentheses is the build number. When iOS is about to install an .ipa, it looks to see if that app is already installed on the device by comparing the bundle identifiers. If it finds a match, it then compares the bundle version values. If they are equal or the one on the device is higher, then iOS aborts the installation. In the image, the 1.0 version number is for marketing purposes and human consumption.

The bundle version number must go up over time. In fact, the App Store and TestFlight won’t accept builds if the number isn’t increased over previous uploads.

With a signed archive in the Organizer, the Distribute App button provides choices about where to distribute the app.

As you build an app, you’ll likely use the Debugging or Release Testing options. For both options, the only devices that can install the .ipa executable are those already registered to the team’s Apple Developer account. For a Debugging release, the app will expire in 60 days. Also, the .ipa will have the debugging hooks enabled.

The Release Testing options can only install on registered devices but don’t expire for a year. Also, the debugging hooks are disabled.

The Enterprise method is only for teams participating in the Enterprise program. Any company with over 250 employees can join the Enterprise program. They can distribute apps within their own company without using the App Store. So, a large company may belong to both the Enterprise program and the regular Developer Program if they distribute internal and App Store apps.

TestFlight and App Store options require that the app ID is associated with a pre-existing entry in the App Store. The team must have already registered that ID with Apple and completed some initial setup on the App Store for new apps, or this must be a new version of an app already for sale in the store.

Once a method is chosen, Xcode and Apple communicate to generate the correct certificates. The developer can then export and distribute the .ipa. For Debugging, Enterprise, or Release Testing, the .ipa can be distributed using a service like App Center or Firebase or on a server where testers can copy the .ipa to their Mac. They can then drag and drop it onto their phone in the Finder to install.