A team that has shipped good web work will often produce an iOS app that users describe as "fine" without being able to say why it feels off. The cause is almost always the same: platform conventions were treated as a visual style to be overridden rather than as behaviour users have already learned, in some cases over fifteen years.
Navigation is a contract
On iOS, a back swipe from the left edge means back. A tab bar means these are peer destinations you can move between freely, and the state of each should survive switching away and back. A modal sheet means you are inside a task and will return to where you were. Breaking these is not bold, it is expensive: every user who has to work out where they are is paying for your novelty, and they pay again on every visit.
The specific failure we see most often is a web team implementing navigation inside a single screen, so the system back gesture either does nothing or exits the flow entirely. If the app has hierarchy, use the platform's navigation for it. If it is genuinely a single surface, say so in the layout rather than simulating pages.
Layout: the safe areas are not suggestions
Respect the safe area insets and the keyboard, and test with the on-screen keyboard raised on the smallest supported device. That combination is where content gets trapped behind a home indicator or a submit button becomes unreachable, and it is invisible on a simulator at default size. Design for a range rather than a canvas: the same screen has to work on a compact phone, a large phone in landscape, an iPad with a split view, and a window on a Mac if you ship there.
- Safe areas top and bottom, plus the keyboard, on the smallest supported device.
- One-handed reach: primary actions belong in the lower half of a phone screen.
- Landscape and split view do not have to be beautiful, but they must not be broken.
- Scroll views that do not fight the system's rubber-band and momentum behaviour.
Where custom design does pay
- The content itself, which is why anyone opened the app.
- Brand expression through typography, colour and motion, inside standard structures.
- Genuinely novel interactions that have no platform equivalent.
- Onboarding, where you have permission to be distinctive and one screen to earn attention.
Everything else is cheaper adopted than invented. System components carry accessibility, localisation, dark mode and future OS changes for free, and a bespoke replacement inherits none of that. The same reasoning applies to icons: the system symbol set aligns with text, scales with it and has consistent optical weight, which a hand-drawn set will not without real effort.
The things that get skipped
Dynamic Type, VoiceOver labels, dark mode, reduced motion and the largest supported text size. These are not accessibility extras on Apple platforms, they are baseline expectations, and a substantial number of users have at least one enabled without ever describing themselves as having an accessibility need. An app that breaks at large text will be uninstalled by people who will never write a review explaining why.
Test at the largest text size before you test on the newest device.
The practical test takes ten minutes: turn Dynamic Type to its largest accessibility setting, switch on Bold Text and Reduce Motion, and walk your three main flows. Anything that clips, truncates a label, or hides a button is a fix. Then turn on VoiceOver and try to complete a purchase without looking at the screen; that is where unlabelled icon buttons announce themselves as "button" and nothing else.
Performance is a design property
Users on Apple platforms are calibrated by first-party apps that launch instantly and scroll without hesitation. A dropped frame reads as cheapness even to someone who could not name what they saw. Budget for launch time and scroll smoothness as design requirements rather than as a late optimisation pass, and test on the oldest device you claim to support rather than the newest one in the office. That device is the one your reviews will come from.
What App Review actually sends back
Most rejections are policy and metadata, not design. The recurring ones are worth knowing before you submit, because each costs a review cycle. Rules change, so read the current guidelines rather than trusting a blog post, including this one.
- An app that creates accounts must also let a user delete their account from inside the app.
- Every permission prompt needs a purpose string that explains the actual reason, not a placeholder.
- Privacy declarations must match what the app and its third-party SDKs really collect.
- Anything selling digital content inside the app has payment rules attached, and those rules have been changing; check them before you build the flow, not after.
- A demo account and clear reviewer notes for anything behind a login, or the submission stalls.
A testing matrix that fits a small budget
You do not need a device lab. You need the smallest current phone, one older device on the oldest OS version you support, and one iPad if you ship for it. Add the two accessibility configurations above and you have covered most of what real users will hit. Simulators are fine for layout and useless for performance, camera, notifications and anything involving real network conditions, so keep at least one physical device in the loop before every release.
Cross-platform is a trade, not a free lunch
Shared codebases are frequently the right commercial call. Just be explicit that you are trading some platform fidelity for delivery speed, decide which specific surfaces must feel native anyway, and spend the saved effort there rather than assuming the framework will hide the difference. Navigation, text input and scrolling are the three places where the difference is most noticeable, and they are the three places worth writing platform-specific code even inside a shared app. Our comparison of React Native and Flutter covers where each one leaves that seam.
The strategic version of this question, which platform to build for first and how deeply to commit to one ecosystem, is a separate decision covered in Apple ecosystem strategy for builders. Get that answer before the design work starts, because it changes what "native enough" means.
The short version
Adopt the platform's navigation, components and type system. Spend your design budget on the content and on one or two moments that are genuinely yours. Test at the largest text size, on the oldest device you support, with the keyboard up. That covers most of the distance between an app that works and an app that feels like it belongs. If you want that judgement applied to a specific product, it is the ordinary shape of our mobile app work and interface design. The strategic reason these conventions are worth following is in the Apple ecosystem strategy for builders.
Abishek Bimali
Founder & Engineer
Abishek founded SiteCraft Innovation and leads its engineering. He writes about building web and mobile products that hold up in production, for teams in Nepal and abroad.
