Search the Community

Hi everyone, I’d like to share a different kind of ProcessWire project. It is not primarily a website: it is the content and application backend for my first native iOS app. Vocapair is now live on the App Store. Vocapair is a vocabulary-learning app built in SwiftUI. The core exercise is simple: match a word with its translation, keep mistakes in the learning loop, and gradually remove mastered words. It also includes listening practice, pronunciation, scheduled review, progress tracking, offline learning, widgets, Game Center, and optional iCloud progress continuity. The original pair-matching reference came from a small web application made by my friend Alexander Dmitriev. I built Vocapair as a separate native product and implementation, but I want to preserve that origin and attribution. Where ProcessWire fits I did not want the app’s dictionaries to become JSON files maintained inside Xcode. ProcessWire became the durable content and operations layer behind the mobile client. The production catalog currently contains: 20 dictionaries; 890 words; 133 categories; 210 phrases; infrastructure for 45 languages, including English; and 1,980 possible learning directions. Those numbers do not mean that every translation has received native-speaker review. ProcessWire lets me keep machine validation, editorial completeness, publication state, and human language review as separate facts rather than one misleading “complete” checkbox. I built a dedicated ProcessVocapair admin module instead of asking editors to assemble the product through unrelated page-edit screens. The module owns the product workflow end to end: dictionaries, categories, words, phrases, and stable UIDs; translation and localization status; dictionary covers and word illustrations; audio preparation and review; StoreKit product mapping and App Store Connect reconciliation; import/export packages; private AI-assisted dictionary planning; and operational verification for the versioned mobile API. Pages and fields remain the storage foundation, but the editor sees a product-specific workspace rather than the underlying storage model. That separation became increasingly important as the catalog grew. Inside the ProcessVocapair workspace The workspace has six stable first-level areas: Overview, Content, AI, Media, Commerce, and System. Each area exposes only the operations that belong to that part of the product. Editors do not need to move between raw page trees, module settings, and generic page-edit forms to understand the state of the app. The AI area is a private planning and review workspace; generated material does not bypass the normal editorial states. The Overview is deliberately operational rather than decorative. It highlights the most important current queue, summarizes the remaining backlog without counting the same item twice, and provides direct routes into Content, Media, Commerce, and System. The Content area connects dictionaries, categories, words, phrases, languages, and stable identifiers. A dictionary can be editorially complete without silently claiming that every translation, audio asset, or image has passed the same review stage. That distinction is especially useful for multilingual work: publication, machine checks, completeness, and human review remain separate, queryable states rather than being collapsed into one percentage. Commerce maps the bounded ProcessWire product records to StoreKit identifiers and reconciles them with App Store Connect. Apple remains the authority for localized prices and entitlements; ProcessWire owns the editorial mapping and operational visibility. API and offline behavior The iOS app reads a versioned API from the ProcessWire installation. The client does not blindly replace its local data after every request. It validates the complete response, writes the new snapshot atomically, and only then makes it visible to the interface. If a refresh fails or the returned catalog is invalid, the app continues using the last valid offline snapshot. The production boundary also includes device attestation and short-lived API sessions. Long-lived server credentials are not embedded in the app. App Attest, session issuance, catalog validation, and local cache replacement were tested independently because “the request returned 200” is not enough evidence that the full mobile path is safe. One thing I appreciated throughout this work was that ProcessWire did not force the backend into a conventional page-shaped public website. I could keep its excellent content model and API while building a completely native SwiftUI interface on the other side. From prototype to App Store I started the first working prototype on August 23. The next day I registered the bundle ID, created the App Store Connect record, and uploaded Build 1 to TestFlight. The speed of that first step was exciting, but it was also slightly misleading: uploading a build is only the beginning of shipping an app. The following weeks included: physical-iPhone testing in addition to Simulator testing; signing and entitlement checks for the app and widgets; App Attest, CloudKit, Game Center, and App Group configuration; StoreKit products, subscriptions, localized storefront prices, and Sandbox lifecycle tests; App Store screenshots, privacy disclosures, age rating, support pages, and review notes; and many interaction changes based on real TestFlight use. The first App Review submission contained 19 items: the iOS app, 14 non-consumable dictionary purchases, three subscriptions, and the All Access subscription group. Apple rejected Build 13 because automatic purchase restoration was not enough; the app needed a clearly visible Restore Purchases control. I added it, tested the exact routes on iPhone and iPad, and uploaded Build 14. The replacement submission was rejected once more, this time for metadata: an optional subscription promotional image was the same as the app icon. I removed that optional image, preserved the required review screenshot, replied in Resolution Center, and resubmitted the same binary. On September 18, Apple approved Vocapair. I manually released version 1.0, Build 14, and the public App Store page appeared a few hours later. The same evening I updated the public website so its landing, support, privacy, and terms pages point to the production App Store listing instead of presenting TestFlight as the main download path. TestFlight remains available as a separate prerelease feedback channel. What I learned My main lesson is that a mobile application is not one artifact. It is a chain: native code, content operations, API contracts, offline state, device security, commerce, legal metadata, beta delivery, review, and storefront distribution. Each link needs its own evidence. AI tools helped me move quickly through implementation, testing, research, and documentation, but they also made verification more important. A generated change was never treated as complete until it passed the relevant boundary: tests, Simulator, physical device, production server, TestFlight, or App Store Connect. For me, this project also confirmed that ProcessWire can be much more than the CMS behind a website. It can be the editorial and operational core of a native product while remaining flexible enough to evolve with that product. Links: Vocapair on the App Store Vocapair website I’d be interested to hear whether others here are using ProcessWire behind native mobile apps. If there is interest, I can write a more technical follow-up about the module structure, stable-UID content model, versioned API, App Attest session flow, and atomic offline cache. Thanks for reading! ProcessVocapair workspace screenshots Overview — live content, media, commerce, and delivery status. Dictionaries — publication state and translation coverage. Words — separate coverage signals for translations, artwork, and audio. Commerce — StoreKit mapping for direct purchases, bundles, and subscriptions. The “App Store showcase” count refers only to optional promoted in-app-purchase cards, not to whether the products are available inside the app.