iOS Development

You need the Developer Program account, in your company name, because that is what the app is published under and what the signing certificates belong to. You do not need Macs in your office; the building happens on ours. Setting the account up early is worth doing, since the organisation enrolment can take longer than people expect and nothing ships without it.

Because an iPhone user notices immediately when an app does not behave like the rest of their phone, even if they cannot name what is wrong. Gestures that go the wrong way, a navigation bar that behaves oddly, type that ignores the size the user chose in settings: each is small and together they read as cheap. Following the platform is also the cheapest route through App Review.

Most rejections we see are not code problems. They are a missing or inaccurate privacy declaration, a permission requested without a clear reason shown to the user, a sign-in that offers no way to delete the account, or payment for digital goods routed outside Apple’s system. All of those are decidable during design, which is where we deal with them.

Only if that is designed for, and it is worth deciding rather than defaulting. An iPhone app enlarged to fill an iPad screen looks like exactly that. If the iPad matters to your users we design the layouts for it properly, including split view and the keyboard and pointer support that turns an iPad into something people work on rather than browse on.

The review itself is usually quick, and it is the wrong thing to plan around. What costs time is a rejection, because the clock restarts and the reasons are frequently things that were decidable months earlier: a privacy declaration that does not match what the app does, a permission asked for without a visible reason, an account you can create in the app but not delete. We prepare declarations, entitlements, reviewer notes and a working demo login alongside the build rather than the night before, and we submit with buffer in front of any date you have announced publicly. Never announce a launch date that has no slack in front of review.

Something changes, every year, and how much it costs you was decided during the build. An app assembled from the system's own components usually needs recompiling against the new SDK and a pass to check the visual changes. An app that reimplemented navigation, controls or gestures itself needs a project, because the custom version now looks and behaves unlike everything else on the phone. This is the practical argument for staying close to the platform, and it compounds: it is not the first September that hurts, it is the fourth.

Yes, and the first checks are specific to this platform. Does it build from a clean checkout against a current Xcode? Are the certificates, provisioning profiles and App Store Connect access reachable by your company rather than an individual who has left? How far behind is it: an app two OS releases back is a straightforward catch-up, one that has not shipped in four years may be carrying deprecated APIs and libraries with no supported successor. We do that assessment as a short fixed piece of work and give you an honest answer, including when the answer is to rebuild.

Yes, and the rules matter more than the code here. Digital goods and subscriptions consumed inside the app have to go through Apple's system, and attempts to route around it are the reliable way to get removed rather than merely rejected. Physical goods and services delivered in the real world do not. The parts that catch teams out are the ones that are not the purchase itself: restoring purchases on a new device, handling a subscription that lapses or is refunded, keeping entitlement state honest when the receipt says one thing and your own server says another. Those are designed in, not bolted on.