AppleGuidelineDrivenFrameworkSelection
title: Apple Guideline-Driven Framework Selection radar_quadrant: Techniques radar_ring: Assess radar_position: inner
This document evaluates six ways to build a mobile app for iOS (the primary platform) with a secondary web version, using a single shared codebase. The lens used throughout is Apple's own App Store review rules, since every one of these approaches will eventually have to pass through the same gate before it can reach customers. The question is not just "which approach is easiest to build," but "which approach carries the least risk of Apple rejecting the app, and what ongoing obligations does each one create."
Two approaches are ruled out immediately because they collide with Apple's rules in a way that isn't fixable by better engineering. Four approaches are viable, and each carries a different balance of building effort versus App Store risk versus long-term flexibility.
Every approach, regardless of which is chosen, must also satisfy a shared set of Apple requirements that have nothing to do with the technology choice: a working privacy policy, honest app-store listing content, and a backend the reviewer can actually reach at submission time. These are described once, since they apply universally, rather than repeated for each approach.
| Approach | Builds iOS the "real" way | Shares one codebase with web | Apple review risk | Best fit if... |
|---|---|---|---|---|
| Approach A (Flet) | Yes | Yes | Standard | Team wants Python and accepts a smaller support community |
| Approach B (Toga) | Yes | Yes | Standard | Team wants Python and prioritizes true native rendering over ecosystem size |
| Approach C (Fully native + separate web) | Yes | No | Standard, but requires two apps | Web usage will stay minimal or is dropped |
| Approach D (Website wrapped in an app shell) | No | Yes | High — likely rejection | Never recommended for this project |
| Approach E (Flutter) | Yes | Yes | Standard | Team is open to leaving Python and wants the largest ecosystem |
| Approach F (React Native) | Yes | Partial — web needs extra adaptation | Standard, with one added review-policy caution | Team is open to leaving Python and already has web/JavaScript skills |
A single Python codebase produces both the iOS app and the web version, using a well-established mobile rendering engine (Flutter) underneath.
Apple guideline exposure: Flet produces a genuinely compiled, self-contained app, so it does not run into Apple's most severe rejection categories. There is no elevated risk tied to the framework itself.
Where the real cost shows up: the friction is concentrated in the process of turning finished code into an Apple-signed, submittable package — a step that has historically caused delays and failed submissions for teams using this tool (flet-dev/flet #5013, #5819, #4831). Once past that step, day-to-day app behavior on iOS is generally sound, though a few mobile-specific rough edges (file selection dialogs, background activity) are still being worked out by the framework's maintainers (#3710, #5958).
A single Python codebase produces both the iOS app and the web version, but instead of borrowing another company's rendering engine, each platform is drawn using Apple's own native interface components directly, via Briefcase.
Apple guideline exposure: same standing as Approach A — a properly compiled, self-contained app with no elevated review risk.
Where the real cost shows up: the packaging step itself is less troublesome than Approach A's, but the framework has more gaps in day-to-day mobile behavior — things like properly closing the app (beeware/toga #1623), keeping up with Apple's newest interface requirements (#3956), and handling the on-screen keyboard cleanly (#2672, #1236) are all still maturing. This is also the smallest community of the six approaches, meaning less outside help is available when something doesn't work as expected (#4139).
The iOS app is built the way Apple itself recommends, using Apple's own tools; the web version, if kept, becomes a completely separate project built with different technology.
Apple guideline exposure: this is the approach Apple's review process is built around, so it carries the lowest inherent review risk of any option.
Where the real cost shows up: this approach does not satisfy the "one codebase" requirement at all — it is effectively two products, built and maintained independently, doubling the ongoing engineering cost every time a feature needs to exist on both platforms. It is included here only as a reference point: if the web version ever becomes unimportant enough to drop or simplify drastically, this becomes the lowest-review-risk option available. Under the current requirement to keep one codebase, it does not qualify as a real candidate.
The app is essentially the company's website, displayed inside a thin wrapper so it can be installed like an app.
Apple guideline exposure: this approach runs directly into one of Apple's explicit rejection categories — apps that amount to little more than a repackaged website are refused outright, by name, in Apple's published guidelines. This is not a matter of doing it carefully; Apple's review guidance describes exactly this pattern as disqualifying.
Conclusion for this approach: not viable for this project and not carried forward into the rest of this comparison.
A single codebase, written in a different programming language than Python, produces the iOS app, an Android app, and a web version, all sharing the same rendering engine that Approach A (Flet) also relies on internally.
Apple guideline exposure: standard — a properly compiled, self-contained app with no elevated review risk.
Where the real cost shows up: this is by a wide margin the most widely used approach of the six, with the largest base of documentation, third-party help, and long-term track record. That popularity comes with a correspondingly large volume of known issues, some of which are cosmetic (visual sizing quirks, flutter/flutter #28894; missing tooltips, #12920) and some of which are more serious (the app failing to display anything at all in certain release configurations, #36247; crashing outright on some devices, #98481; media playback failing, #47030). The framework is also still catching up to Apple's newest visual design language at the time of this research (#170310). None of this creates Apple review risk directly, but it does create quality-assurance risk that a team would need to budget testing time against.
A single codebase, again in a different programming language, produces the iOS and Android apps natively; the web version is not automatic and requires an additional adaptation step rather than coming for free.
Apple guideline exposure: standard for the core approach, but this is the one option in the comparison with a framework-specific caution worth flagging to decision-makers. Apple's rules explicitly prohibit apps from downloading and running new code after they've already been approved, as a way of changing what the app does without going through review again. This particular technology's ecosystem includes popular tooling built specifically to do exactly that — push code updates to users instantly, bypassing the normal app-store update and review cycle. Used within Apple's rules, this is fine; used as intended by some of that tooling's marketing, it edges toward the exact behavior Apple's guidelines prohibit, and Apple has taken enforcement action against apps using it that way before. This is a policy discipline risk more than a technical one — it depends entirely on how the team chooses to use the tooling available to them.
Where the real cost shows up otherwise: a smaller number of open, known issues than Flutter (react/react-native #42939, #29290, #53450, #29068, #54859, #28557), which may suggest either a better-maintained project or simply a smaller overall surface area since it relies more on the underlying operating systems' own components. Web is not a natural output of this approach the way it is for the Python and Flutter options — it requires a genuinely separate adaptation layer, partially undermining the "one codebase" goal for the web target specifically.
These come directly from Apple's published App Store review rules and are unrelated to any technology decision above. Any approach chosen still has to clear all of these:
- The backend must be reachable when Apple reviews the app. If the data an app needs comes from a file bundled inside the app itself (as a starting CSV or JSON file would be), this is automatically satisfied. The moment that data instead comes from an online database, as is planned for later, that database has to be genuinely online and accessible at all times an Apple reviewer might test the app — this becomes a new, ongoing hosting responsibility that doesn't exist at the CSV/JSON stage.
- The app-store listing has to accurately represent the app. Screenshots must show the app actually being used, not marketing artwork, and the written description cannot describe features that don't exist yet or hide features that do.
- If anything inside the app is ever sold, it must be sold through Apple's own payment system. A company cannot build its own separate mechanism to unlock paid features or content within the app; Apple requires its own purchase system be used for that, and takes a share of the revenue as a condition of that system.
- A privacy policy is mandatory, and the app must ask permission before collecting any personal information, even information the company considers anonymous. If the app allows user accounts, it must also let users delete their account.
- Review timing is not guaranteed. Apple does not promise a fixed turnaround time, and an app can be rejected shortly before a planned launch date with no fast-tracked path to resubmit. Any hard launch date should have buffer time built in to absorb at least one review cycle.
Two of the six approaches are eliminated outright: the website-wrapped app fails Apple's rules directly, and the fully-native-plus-separate-web approach fails the one-codebase business requirement, though it remains the fallback if that requirement is ever relaxed. Among the four that remain viable, none of them carries elevated Apple review risk on its own — the real differences are in how much engineering friction and ongoing maintenance risk each one creates, and, for React Native specifically, a policy discipline requirement around how code updates are delivered after launch. The universal Apple requirements — a reachable backend at review time, honest listings, mandatory privacy handling, and unpredictable review timing — apply regardless of which of the four is chosen, and deserve to be planned for now rather than discovered at submission time.
Ranked against the stated business requirements (iOS primary, web secondary, one codebase, Python preferred), the four viable approaches order as follows:
- Approach A (Flet) ranks first as the best match to the stated Python preference. It satisfies the one-codebase requirement cleanly and carries no elevated Apple review risk; its packaging friction is a one-time, front-loaded release cost rather than an ongoing behavioral risk.
- Approach E (Flutter) would rank first on sheer maturity and ecosystem size alone, and is excluded from that position only because it means leaving Python — an organizational cost rather than a technical one. If the Python preference turns out to be flexible, this is arguably the safer long-term bet given its scale of adoption and documentation.
- Approach B (Toga) shares Flet's Apple risk profile and Python fit, but ranks below it due to a smaller community and more unfinished mobile behavior (app lifecycle handling, keyboard behavior, keeping pace with Apple's newest interface style). Its advantage — true native rendering rather than borrowing another company's engine — is real, but currently comes with more rough edges to work around.
- Approach F (React Native) ranks last for this project specifically, not as a general judgment on the framework. Two project-specific mismatches drive this: web is not a natural shared output the way it is for the other three, undermining the one-codebase goal for that target, and it is the only approach carrying a distinct App Store policy-discipline risk that must be actively managed rather than simply tested for.
If Python is a hard requirement, the practical decision narrows to Flet versus Toga: ecosystem size and easier packaging (Flet) against closer-to-native rendering and fewer borrowed dependencies (Toga).
This entry is placed in Techniques because its subject is a decision method — evaluating app-building approaches through the lens of Apple's App Store review rules — rather than any single tool or platform. It is placed in Assess because no first-person production use has occurred yet; this document represents research and comparison ahead of an implementation decision, not a confirmed pipeline. Placement is inner, reflecting that the underlying source material (Apple's published guidelines, and each framework's own public issue tracker) is well-documented and independently verifiable, making the technique's conclusions readily actionable even without production confirmation yet.
