How to publish your iOS app in the app store if you outsourced its development

Let's say you're a business person with a great idea for an app, yet you have no interest or inclination in doing software development, hence you hand it over to an outsourcing partner. Assuming it all goes well, in due time you'll have a working app that's ready to be published to the world. The development team produces the source code for the app, and possibly some installation package (IPA) that allows you to test it on your device. All looks good and you decide to have the app published under your own account, assuming you enrolled in Apple's iOS Developer Program.

First off, why would you want to use your own account ? It allows you to promote your brand, by showing you as the "Seller" of the app in the app store. It also allows you to directly collect any proceeds from selling the app, or any in-app purchased content, if the app or its content it's not free. In most cases these are strong enough reasons to shell out the required annual membership fee (which at the moment stands at the equivalent of $99 USD). If these don't matter to you, you're better off using the account of your outsourcing partner for publishing.

Assuming you applied and got your membership in Apple's iOS Developer Program you'll have to assist your developer in publishing the app under your own account. Here you can work under 2 possible scenarios:

1. New account

If this is a brand new account, that is, you don't have any existent apps live in the App Store, the best course of action is to hand over to your (trusted) developer the credentials for logging into your account and let them do their thing. This may be stepping beyond the terms of service imposed by Apple, but it's the hassle-free option. You'd cede the access only temporarily, until your app is set up, then you can change the password of the account to take back control.

The alternative workflow, endorsed by Apple, is to add the developer to your account, in a "Developer" role, assuming you have a company account, that is, not an individual account. Company accounts allow having different members under the same account, with different roles. The workflow envisioned by Apple may work well for companies with in-house development expertise, but I found it quite lacking in cases where companies outsource the development as a whole, and have no such expertise (like most of my clients). The reason is that only the person in the "Team Agent" role can submit apps and app updates to Apple for review and inclusion in the App Store. The other members of the account can contribute towards the development of the app, by writing source code, testing, etc, but there's only one person that acts as a gatekeeper for the submission process. By default the Team Agent is the person who applied for the account, who, as a representative of the contracting party, in most cases has no interest or knowledge of the technicalities of building an app. That's why I'd recommend to give your outsourcing partner access to that role.

2. Pre-existent account

This is the case where you have already an account, that was used to publish some other apps, possibly developed by other developers. In that case, besides giving them access to the Team Agent role, you should do one more thing. You see, all apps get digitally signed before they are submitted to Apple for inclusion in the App Store. This signing takes place automatically when the app is being built by the Team Agent and relies on a unique development certificate that must be set up by the Team Agent. If you have ceded that role to a developer, who had that set up for your account, and now you're switching to a new developer, the new developer must have access to that certificate too. When that certificate is set up it produces 2 parts. One is a public part, which is the certificate itself, which encloses a public key. This public part gets stored in Apple's development portal and can be accessed by anyone who has access to the account. The private part gets stored locally on the computer of the person who set up the certificate. If a new person is to use the same certificate for signing purposes she must also get access to that private key. For that you'd need to ask your previous developer to export the private key, as shown in the figure below, and pass it to the new developer.

It's best to ask your developer to give you a copy of the private key, as soon as the certificate gets created, even before you embark on new development projects.

If for some reason you can't receive the key from the previous developer, not all is lost, the new developer in Team Agent role has the option to revoke the old, existent certificate and create a brand new one, with a private key that would be in her control. Although it sounds like a pretty drastic measure, it's really quite benign, as described in Apple's official docs. Your new developer may need to do this anyway if the key passed from the previous developer fails to import properly. I can attest for the effectiveness of the method, as I performed it several times for different clients.

Reverse-engineering iOS apps through console output and logging

One useful practice in software development is the use of logging, to record details about the status of the app, or other events of interest at runtime. This can be a life saver when problems occur and they need debugging, either live or post-mortem. The logs are also useful during the development of the app, as a way to quickly asses its sanity, at a glance, as opposed to placing breakpoints and using the debugger to inspect the value of variables of interest. In some instances, where timing issues could affect the behaviour of the app, stopping the execution with breakpoints is infeasible, possibly resulting in heisenbugs. In such instances logging can be a better alternative. So you'll find logging used heavily on all types of apps.

In iOS we have this function, part of Foundation framework:


NSLog

Logs an error message to the Apple System Log facility.

void NSLog (
   NSString *format,
   ...
);

Its use is encouraged in many introductory books and tutorials for iOS programming. By default this function outputs content to the device console available through the Organizer view of Xcode. Now, while this is all good for debugging apps that we're developing, I was very surprised to discover output produced by 3rd parties apps, that were installed straight from App Store, in this case "Globe News". I obtained this output by simply running the app on my iPad set up for development, connected to my laptop running Xcode:

In many cases such output may contain sensitive information, like details of various web services endpoints used by the app, or other information that could be used for reverse engineering. This may well be a bug in this particular combination of Xcode/iOS versions, but as developers we need a way to guard against this.

Another concern is the overhead incurred by having our code peppered with such NSLog statements. Each time such a statement is executed, depending on how efficient its internal implementation is, its input parameters may be processed and a string may get formatted, even if there isn't an output sink available. And on mobile devices, like those powered by iOS, where every wasted CPU cycle translates in battery drain, this is of particular concern.

A popular way to control logging is to enable it only in debug builds, by wrapping the calls to logging functions in some macros. For iOS we could use this setup:

#ifdef DEBUG

#    define DLog(...) NSLog(__VA_ARGS__)

#else

#    define DLog(...) /* */

#endif

#define ALog(...) NSLog(__VA_ARGS__)

This snippet can be placed in the _Prefix.pch file, that makes the macro available in all source files. Using this macro enables logging only on debug builds, hence getting rid of all problems mentioned above. Your released app, available in the App Store wouldn't even have any logging compiled in, hence it would be better protected against reverse engineering.

Obvious shortcomings of Apple's App Store

Having published more than 40 apps in the App Store, on behalf of my clients, I'm in a good position to comment on possible ways to improve it.

Perhaps the most glaring omission is the inability to quickly revert to a previous version of an app, once a newer update has been approved and went live. Sometimes mistakes occur, and those mistakes could easily go live.  Based on my experience, once an account has a fair number of apps published (like over 30), and an unblemished history, with few app rejections, it seems that Apple's review process gets noticeable lax (as a better word for sloppy). In one instance an app update was glaringly broken on retina display devices (i.e. iPhone 4), yet it was approved and went live.

In such instances your only recourse is to either pull the app from the store, and/or to prepare and issue a new update, but that has to go back to the waiting queue. This could have terrible business consequences, because there wouldn't be a working app available for about a week. You could try to speed it up, by requesting an expedite review. Although the onus is on the developer to test each update before publishing it, it'd be very helpful to be able to revert to a previous, functioning, version.

A related idea would be to have some sort of a staging area, whereby a new app, or an update of an existent app, could be made available through an obscure URL to a set of testers, after it has been reviewed, but before being made available to the public at large. This may be already supported through the option of manually releasing the app after the review completes, though the fact that there's a single URL that points to the app in the store, irrespective of its version, may suggest that the URL points to the latest live version. This staging area mechanism would be similar to the Ad-Hoc distribution, only more scalable.

Another thing missing is an API to access the App Store functionality programatically. Some apps lend themselves to a cookie cutting model, whereby the same template is used to produce multiple apps, perhaps being differentiated by the content they package and some branding. In such instances the ability to programatically interact with the store would be very useful.