--- title: iOS App Development description: A practical guide to iOS app development covering Swift, App Store approval, architecture, budgets and how to choose iOS app developers. image: https://weareaffective.com/hubfs/learning-centre-images/ios-app-development.webp --- [Skip to content](https://weareaffective.com/learning-centre/ios-app-development#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # iOS App Development Table of Contents We worked on a social football platform that launched on iOS first, and day one adoption came in at around half the level the launch plan had assumed. The audience was young and skewed heavily towards Android, so the iOS app development work handed the most polished version of the product to the smaller part of the market. Within a few months the client had brought in advertising and dropped the subscription model they'd spent a year designing around, because there simply weren't enough users to carry it. > The decisions that sink an app are nearly always made before anyone writes code. That's the pattern we keep running into. The expensive problems live in the first few weeks, in choices about platform, audience, scope, architecture and who holds the developer account. Code is the cheap part to change. A platform decision made on a hunch in week two can still be costing money three years later. What follows is the sequence of decisions in the order you'll actually meet them, from [working out whether iOS deserves to go first](https://weareaffective.com/how-to-create-an-app), through discovery, architecture and design, to Apple's review process and the account admin nobody thinks about until it bites. Most of it comes from projects we've run and, in a couple of cases, from projects that didn't make it. ## Deciding Whether iOS Comes First iOS first makes sense when your revenue comes from in-app purchases or subscriptions and your audience is genuinely carrying iPhones. The spending side of that holds up. According to [Business of Apps](https://www.businessofapps.com/data/app-statistics/), 45% of iOS users buy at least five premium apps, against 19% of Google Play users. If people are paying you inside the app, that matters. The audience side is where the football platform came apart. The demographic was younger and proportionally Android-heavy, and nobody had checked that against the launch plan before the build started. We ended up with a good product in front of the wrong half of the market on day one, and the commercial model had to be rewritten after launch rather than before it. #### When iOS app development goes first We now ask three questions before anyone commits. What phones does this specific audience hold, with evidence rather than assumption. Does the revenue model lean on in-app payment or on scale and advertising. And what happens to the business case if day one numbers land at half the forecast. If the answers point to Android or to both, iOS first is still possible, but the money model has to survive the smaller start. That's the part the football client didn't get to test. ## Validating Demand Before Anyone Writes Code We worked on a product aimed at African communities living abroad, designed to help people keep a connection with their home communities. The build was straightforward, the idea was likeable, and the client was ready to go. We ran focus groups with the target market first, and the research came back flat. There just wasn't the desire for that kind of product among the people it was built for. A second problem sat underneath that one. The devices commonly used in African countries at the time were limited in what they handled, so delivering half of the intended experience on them was going to be very hard. Two separate reasons to stop, and both of them surfaced for the price of a few focus groups rather than a few hundred thousand pounds of engineering. Validation work on an iOS product is rarely glamorous. It's conversations with real users, rough prototypes, a landing page, sometimes a short set of workshops. What it buys you is permission to spend properly on the things that survive contact with the market. Run your demand research against the devices your audience actually owns, not the ones in your office. Capability gaps in the real device base shape what you can promise. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Native Swift or Cross-Platform Native Swift gives you [full access to the device](https://weareaffective.com/learning-centre/can-cross-platform-apps-access-all-phone-features-like-native-apps) and a product that behaves like an iPhone product by default. Cross-platform gives you one codebase and a much smaller bill. [Topflight Apps](https://topflightapps.com/ideas/app-development-costs/) put cross-platform at roughly 30 to 50% cheaper than two native builds, based on their own project work, and that holds where the app sticks to standard interface patterns and doesn't lean hard on device hardware. The honest version of this decision is that it depends on what the product does at its edges, so here's how we weigh it. > The stack question is cheap to answer early and brutal to revisit six weeks before launch. On the concierge app we built for a property developer, discovery cut the feature list right back to something simple and human. A product that lean has no need for two separate native codebases. | What you're weighing | Native Swift | Cross-platform | | --- | --- | --- | | Build cost for both platforms | Highest | Lower, single codebase | | Deep hardware access | Direct | Via plugins | | Offline and background work | Fine control | Workable, needs care | | Team you need | iOS and Android specialists | One team | | Feel on an iPhone | Native by default | Close, with effort | [Pick on the edges of the product](https://weareaffective.com/learning-centre/what-makes-some-apps-easier-to-build-than-others), because that's where the stack either helps you or fights you. ## Where Discovery Can Be Skipped, and Where It Cannot On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery on the messaging side and put everything into onboarding. We built the onboarding properly. The messaging got built generically, because nothing told us otherwise, and it allowed automated and fake messages, which is exactly what all that verification work existed to stop. The two halves of the product contradicted each other. The messaging section had to be rewritten, at around £15,000 of extra budget and two extra months of work. Discovery on one part of a product and not the others produces a product that argues with itself. #### What discovery bought on the concierge app The property developer building a concierge app for high-rise buildings came to us with a budget and a formed idea, really wanting a sign-off rather than a scope. We talked them into proper discovery with focus groups and user workshops. What we found was that the product needed to be a lot simpler than they'd pictured. Plenty of planned features never got built, and we focused instead on creating a human connection with the product rather than replacing systems the building already had. Better product, lower cost, and the research paid for itself before the first sprint. ## Architecture Decisions You Cannot Undo Later On a travel product aimed at younger backpackers heading to off-grid places, connectivity was the whole design problem. Sporadic signal was the normal state of the user. That meant rethinking the architecture from the data layer up rather than bolting an offline mode on at the end. We worked through four decisions in order. 1. What information can be stored offline on the device 2. What genuinely has to stay online and live 3. How actions taken offline get queued and replayed once the user reconnects 4. How to cut the data moving between app and server to make the most of thin bandwidth Anything we were able to bake into the product itself, we did. Everything else stayed as light as possible. The result worked offline where that was feasible and used whatever connection the user found efficiently. You can redesign a screen in a day. Changing how data syncs after launch, with users holding local state on their phones, is a different kind of job altogether, and it tends to arrive at the worst possible moment. Write down your offline rules before the first build sprint, even if the answer is that the app needs a connection for everything. The decision being explicit is what matters. ## Designing an App People Keep Opening We ran an [audit on a genetics wellness app](https://weareaffective.com/learning-centre/why-a-wellness-genetics-product-needed-a-rewrite-before-it-needed-a-redesign) where retention was the problem. What the audit found surprised the client. The brand promise was fine. The narrative of giving someone a real inside look at how their body works, how it's ageing and how they can improve on it was well built and genuinely compelling. The product was the issue. It had been built largely by a developer team, and the storytelling had been stripped out along the way in favour of functional delivery. Users were looking at their own genetic data and feeling nothing about it. Numbers on a screen, no sense of who they were inside the product, no reason to come back next week. #### Designing for the second visit So the work was reintroducing narrative and giving people an identity within the product, rather than touching the brand promise at all. That meant results framed as a story about the person, progress they can see themselves in, and micro moments that acknowledge what they've done. Retention design is mostly emotional. [People reopen apps that make them feel something](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them) about themselves. A functional product that answers a question perfectly gets opened once, and then it sits on the fourth screen of somebody's phone forever. ## Your App Store Listing, Icon and Category On a gifting and wishlist platform we worked on, the client was hesitant to spend anything on the App Store listing. The product was social and group-based, so they believed word of mouth would do the job. Our view was that referral and listing work pull in the same direction. The icon, the copy, the category and the screenshots all need to make the [product immediately clear, because that's what lets someone decide](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) in or out before they ever download. Get that right and the people who do install are already pre-sold. They open the app knowing what it's for, which pulls early abandonment right down. > A listing that tells the truth quickly is the cheapest retention work you'll ever do. Category choice carries more weight than most founders expect, given that [Stormy.ai](https://stormy.ai/blog/asa-to-aso-keyword-loop-strategy) puts over 65% of app downloads as starting organically. Where a product sits plausibly in two categories, we advise clients to start in the less competitive one. Ranking is easier there, which builds impressions, downloads and usage, and the move into the tougher primary category becomes a later decision made from a position of traction rather than from a standing start. ## Surviving Apple's Review Process On a currency exchange app we worked on, the client met every compliance requirement Apple stated, and the app kept getting rejected. Each time we resolved the stated objection, a new one appeared. Apple eventually raised the possibility of the product being used for money laundering and criminal activity, so we capped transactions at €150, which should have closed that line of argument completely. Rejected again. The client ran out of budget and abandoned the product. Apple Pay and other payment services launched a little while afterwards, and we believe the two things were connected. There's no real mechanism for a developer to challenge that pattern, which is the uncomfortable part. Most review experiences are nothing like this. In 2024 Apple rejected 1,931,400 submissions out of 7,771,599, close to a quarter, and the [Apple 2024 transparency report](https://www.apple.com/legal/more-resources/docs/2024-App-Store-Transparency-Report.pdf) puts around 1.24 million of those down to performance violations, meaning apps that crash, freeze or fail to show their features working. That's more than every other rejection category combined, and it's the one category entirely within your control. #### Before you submit Test on real devices, give the reviewer working demo credentials, and make sure every feature in your screenshots actually runs. ## Who Controls the App Store Connect Account On the social football product, the client set up App Store Connect in their own name and held the Account Holder role. They gave us admin access across most of the account, and we built a testing structure around it with three groups. - An internal group for our team - An internal group for the client - An external QA beta group for the client's own testers That let us control which build reached which group at each stage of deployment, which is the whole point of having groups at all. As launch approached, the client started going into the account and pushing already-uploaded builds out to whoever they wanted. It caused problems, and because everything sat on their account with full access, there wasn't much we could do to stop it. The client owning the account is correct. It's their asset, their business, and handing it to an agency creates a far worse problem later. The thing that needs agreeing up front is how it gets used, who promotes builds, and what happens when someone wants to shortcut the process in launch week. Agree your build promotion rules in writing at kick-off, while everyone is calm. Nobody negotiates process well with a launch date four days away. ## Budgets, Timelines and Choosing iOS App Developers Budget overruns on the projects we've run rarely come from engineering being slow. The dating app messaging rewrite cost around £15,000 and two months, and all of it traced back to a decision to skip discovery on one section of the product. Money saved at the start, paid back with interest halfway through the build. The concierge app went the other way. Discovery cost money the client hadn't planned to spend, and it removed enough features from the scope that the whole project landed cheaper than their original estimate, with a better product at the end of it. #### What to ask iOS app developers [Ask how they handle discovery](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need), and what they do when a client wants to skip it. Ask who owns the App Store Connect account and the code. Ask what they'd cut if the budget dropped by a third, because the answer tells you whether they understand your product or just your feature list. Ask to see a project that went wrong. Good iOS app developers push back. The social football client, the dating app client and the property developer all got advice they didn't initially want. The one who took it got the best outcome. ## Conclusion Across the iOS work we've done, the projects that struggled share a shape. Something got decided early without evidence, whether that was the platform on the football product, the messaging scope on the dating app, or the listing work on the gifting platform. Then the build went well, the team was capable, and the product still arrived carrying a problem it was born with. The projects that went well share a different shape. Somebody spent a small amount of money early to find out whether the assumption held. Focus groups killed one product before it cost real money. Workshops made another one simpler and cheaper. An audit found that the brand promise was sound and the storytelling had been lost in the build, which is a far more useful answer than a redesign. None of that requires a bigger budget. It requires spending a slice of the budget on questions rather than code, at the point where the answers can still change what you build. If you're weighing up an iOS build and you're not certain the early decisions are right, we're happy to be the awkward second opinion. [Let's talk about your iOS app](https://weareaffective.com/get-started). ## Frequently Asked Questions How do I know whether to launch on iOS first or Android first? Check what phones your specific audience actually carries, using real evidence rather than assumption, and look at whether your revenue comes from in-app payments or from advertising and scale. iOS tends to suit subscription and in-app purchase models, because iOS users spend more readily on premium apps. If your audience skews Android, iOS first can still work, but your commercial model has to survive a smaller starting user base. Why does the platform decision matter so much if code can be rewritten? Code is the cheap part to change, whereas platform, audience and architecture choices shape the commercial model for years. A platform call made on a hunch in week two can still be costing money three years later, as happened with a social football platform that had to abandon a subscription model it had spent a year designing around. What happens if day one adoption comes in well below forecast? It can force a complete rewrite of your revenue model after launch rather than before it, which is far more expensive and disruptive. Before committing, ask what happens to the business case if day one numbers land at half the forecast. If the answer is that the model collapses, you need a different plan or a different platform order. What does demand validation actually involve? It is usually unglamorous work, conversations with real users, rough prototypes, a landing page and sometimes a short set of workshops. The point is not to produce polished output but to buy permission to spend properly on the parts of the product that survive contact with the market. Can validation research really stop a project that seems like a good idea? Yes, and that is often money well spent. One product aimed at African communities living abroad looked likeable and was ready to build, but focus groups with the target market came back flat. The research cost a few focus groups rather than a few hundred thousand pounds of engineering. Should device capability form part of early research? Absolutely, because a product that works beautifully on a current iPhone may be unusable on the handsets your audience genuinely owns. In one case, the devices commonly used in the target countries could not support half the intended experience, which was a second independent reason to stop. Test your concept against the actual hardware in users' hands. Does the higher spending of iOS users justify going iOS first on its own? No, spending power only matters if your audience is genuinely on iPhones. Around 45% of iOS users buy at least five premium apps, compared with 19% on Google Play, but that figure is irrelevant if your users are mostly on Android. You need both the spending behaviour and the device match before iOS first makes commercial sense. Who should hold the Apple developer account? This is the sort of admin detail nobody thinks about until it causes problems, so settle it early and in writing. The account should sit with the business that owns the product, not with an individual developer or agency, so you keep control of releases and the App Store listing if the relationship changes. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.