iOS and Android Mobile App

AFA Council Mobile App Developer Scope of Work and Fixed-Bid Requirements Project type Cross-platform mobile app development for iOS and Android Design and prototype The approved interactive prototype is the primary visual and UX reference for this project: View the AFA Council App Prototype in Figma: https://www.figma.com/proto/PZYwwSTlBrWgf37wFQNVWH/AFA-Council?node-id=3-67&t=x2dOAoI5vYzvXMsH-1&scaling=scale-down&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=1%3A3 Nyquist Design will provide the completed product design, Figma files, design system, content, and working calculator HTML files. This engagement is for development services. The developer is responsible for implementing, testing, packaging, documenting, and publishing the app based on the approved designs and requirements below. 1. Project Summary Develop and publish an offline-first mobile application for AFA members on: Apple iOS Google Android The application will include: Three locally embedded HTML calculators Four offline searchable documents Five to seven quick-reference cards A phone directory Optional Auth0 member login Guest access RSS-driven articles Push notifications linked to articles Newsletter signup with offline queueing Google Calendar events External resource links The app must remain useful without internet access. Login may not block access to the app’s core offline content. 2. Development Approach The preferred technical approach is: Ionic and Capacitor TypeScript React, Angular, Vue, or another maintainable front-end framework Native iOS and Android projects generated through Capacitor Local database/storage suitable for offline content and search An equivalent cross-platform approach may be proposed, but the developer must explain how it will support: Client-supplied HTML calculators Offline-first functionality Local document search Auth0 Push notifications RSS synchronization App Store and Google Play publication The developer’s fixed bid must include all platform-specific implementation required for both iOS and Android. 3. Design Handoff and Implementation Nyquist Design will provide: Approved Figma designs Interactive prototype Design system App icons and graphic assets Final screen content Three completed calculator HTML packages Documents, directory content, quick-reference content, and links Design review and implementation feedback The developer will: Build the app to materially match the approved Figma Implement all designed screens, navigation, components, and states Account for iOS and Android safe areas Ensure layouts work across common phone sizes Implement loading, offline, empty, success, error, and disabled states Correct material deviations from the design before final acceptance Default framework styling may not be substituted where the Figma defines a specific design. 4. Authentication and Guest Access Auth0 login The app will support optional AFA member login using Auth0 Universal Login. The developer will implement: “Sign in with AFA” Auth0-hosted login and password-reset flow Login cancellation and error handling Secure token storage Session restoration Logout Expired-session handling Required iOS and Android callback/logout configuration A custom in-app username and password form is not included. Guest access The app must also provide a clear Continue as Guest option. Guest access must work: On first launch Without internet access When Auth0 is unavailable When the user does not have an AFA account When the user chooses not to sign in Guest users must be able to access: All three calculators All four bundled documents Offline document search Quick-reference cards Phone directory Unless AFA identifies content as restricted before development begins, other public app content should also remain accessible to guests. Authentication may not create a mandatory gate that prevents users from entering the app. 5. Calculator Integration Nyquist Design will provide three completed calculator packages as HTML files: Duty Max Calculator Domestic International Reserve Fly-Through Calculator Holiday Pay Calculator The developer is not responsible for creating or interpreting the calculator business logic. The developer will: Bundle the calculator files locally within the app Preserve the supplied formulas, control order, defaults, and behavior Ensure all calculator resources work offline Remove or localize remote fonts, scripts, styles, images, or other dependencies Integrate each calculator into the app navigation Ensure touch controls, scrolling, selectors, toggles, tooltips, and result displays work on iOS and Android Test all supplied calculator test cases Correct any defect introduced during integration The calculators must not require: A remote webpage A CDN An API An internet connection Changes to calculator business rules after final delivery of the HTML files are outside the developer’s fixed scope unless separately approved. 6. Offline Searchable Documents The app will include four documents supplied by Nyquist Design/AFA. Required functionality: Documents bundled with the app Full offline viewing Full-text search across all four documents Search results showing: Document title Relevant text snippet Selecting a result opens the corresponding document Search works in airplane mode The developer will: Extract machine-readable text Build and bundle a local search index Implement case-insensitive keyword and phrase search Provide clear no-results and error states Ensure search does not freeze the interface SQLite full-text search or an equivalent reliable local-search solution is acceptable. Page-level jump-to-result and in-document highlighting are required only if shown in the final Figma and technically supported by the source documents. OCR of image-only or poorly structured documents is not included unless identified before the fixed-price estimate. 7. Quick Reference and Directory Quick-reference cards The app will include five to seven offline cards. Each may include: Title Body text Icon or image The developer will implement the swipe or navigation behavior shown in Figma and store the content in a simple maintainable format such as JSON. Phone directory The app will include approximately 10–15 entries. Each entry may include: Name Role Phone number Email address, where supplied Required functionality: Available offline Tap to call Tap to email where applicable No search feature required 8. RSS Articles and Offline Cache The app will include an Articles section populated from an AFA-provided RSS feed or article API. Required functionality: Article list Article detail screen Headline Date Excerpt Article body Images, where supplied External links Manual refresh Automatic refresh when appropriate Duplicate prevention Last updated status The app must cache synchronized articles for offline viewing. The developer will: Store article metadata and body content locally Cache article images where practical Sanitize feed-provided HTML Update existing articles when the source article changes Retain up to 100 recent articles unless another limit is approved Handle unavailable or incomplete feed content gracefully AFA must provide a full-content RSS feed or an article API. Custom website scraping is not included. 9. Push Notifications The developer will implement push notifications for iOS and Android using the appropriate Apple and Firebase services. Notifications must support: Title Message Article identifier or URL Deep link to the related article in the app Required behavior: Receive notifications when the app is open, backgrounded, or closed Open the related article when tapped Retrieve the article first if it is not already cached Display a reasonable error if the article is unavailable Request notification permission appropriately Support users who decline notifications The fixed scope includes app-side notification receipt and article deep linking. It does not include development of: A custom notification admin portal A new CMS plugin An automated publish-and-send system The developer must identify how AFA staff will send notifications using an existing service or system. 10. Newsletter Signup and Offline Queue The newsletter form must work online and offline. When online: Validate the email Submit to the AFA-provided newsletter endpoint Display success or error messaging When offline: Validate the email locally Save the request in persistent local storage Inform the user that it will be submitted later Retry when the app is open and connectivity returns Remove the request after successful submission Prevent duplicate pending requests for the same email Guaranteed submission while the app is fully closed is not required because mobile operating systems restrict background processing. AFA will provide the newsletter provider, API documentation, required fields, endpoint, authentication details, and test access. 11. Google Calendar The app will display events from one AFA-provided Google Calendar. Required functionality: Calendar or event presentation shown in Figma Event title Date and time Location Description Event link All-day events Recurring events Event detail view The app must: Cache the last successful event synchronization Display cached events offline Show an appropriate state when no cached data exists Support manual refresh The integration may use: Public ICS feed, or Google Calendar API The developer must identify the chosen method in the estimate. 12. External Links The app will include three to five client-provided external links. Links must: Open in the system browser unless otherwise shown in Figma Display a clear error if the link cannot be opened Fail gracefully when the device is offline External webpages do not need to be cached. 13. Offline-First Requirements The following must work without internet access: App launch Continue as Guest All three calculators Four documents Document search Quick-reference cards Phone directory Previously downloaded articles Previously synchronized calendar events Newsletter signup queueing The app must not: Block on authentication Require an initial server response before showing bundled content Display an unusable blank screen Lose queued newsletter signups Show endless loading indicators when offline The developer must test these conditions in airplane mode on physical iOS and Android devices. 14. Testing and QA The developer is responsible for: Functional testing Integration testing Offline testing Cross-platform testing Regression testing Store-release testing Testing must include: Fresh install Guest entry Auth0 login and logout Login failure Session expiration Offline launch Connectivity loss and restoration Calculator operation Document search RSS synchronization Article rendering Push deep linking Newsletter queue and retry Calendar synchronization External links Tap to call App background and foreground behavior At minimum, final testing must include: One current iPhone One older supported iPhone One recent Pixel device or emulator One recent Samsung device or emulator Physical devices must be used for final authentication, push notification, link, and offline testing. 15. App Store and Google Play Submission The developer’s fixed bid must include: Apple Bundle identifier Signing and provisioning Push entitlement Auth0 callback configuration TestFlight build App Store Connect submission Required privacy and SDK declarations Google Package ID App signing Firebase/FCM configuration Internal or closed-test build Production Android App Bundle Google Play submission Data Safety technical details Also included: One initial submission to each store One reasonable round of store-review corrections Resubmission The developer cannot guarantee store approval but must deliver an app that complies with the applicable published requirements at the time of submission. 16. Developer Deliverables The fixed bid must include: Complete iOS application Complete Android application Source-code repository Native iOS and Android project files Locally embedded calculators Offline document search Quick-reference cards Directory Auth0 login and guest access RSS articles and offline cache Push notifications Newsletter offline queue Google Calendar integration External links TestFlight build Google Play testing build Production store submissions One store-review correction round Build and deployment documentation Content-update documentation Third-party SDK inventory Privacy disclosure technical details One handoff session of up to 90 minutes The repository and all development accounts created for the project must be owned by Nyquist Design or AFA, not solely by the developer. 17. Acceptance Criteria The project is complete when: The app materially matches the final Figma Both iOS and Android builds function correctly Users can sign in or continue as guests The app can be opened and used offline All calculators work offline and match supplied test cases All documents can be opened and searched offline Cards and directory work offline RSS articles synchronize and cached articles open offline Push notifications open the correct article Newsletter submissions queue offline and later submit Calendar events synchronize and remain available offline No reproducible critical or high-severity defects remain Production builds pass Apple and Google technical validation Source code and documentation are delivered 18. Explicitly Out of Scope Unless separately approved in writing: Calculator design or business-rule development Custom username/password login UI New authentication backend New CMS Custom notification portal Automated push sending from article publication Website scraping User-generated content Direct messaging Payments or subscriptions Advertising Multilingual support AI or semantic search Advanced analytics dashboard Remote editing of bundled documents, calculators, cards, or directory content Desktop or web app Tablet-specific designs not included in Figma Ongoing maintenance after the warranty period 19. Warranty and Change Control The developer’s fixed bid must include a 30-day defect warranty after final release or delivery of production builds. The warranty covers reproducible defects within the approved scope. It does not cover: New features Changed requirements Client content changes Third-party outages Platform or API changes after acceptance Changes made by another developer Additional fees require a written change order approved before work begins. A change order must identify: The requested change Why it is outside this scope Cost Schedule impact The developer may not charge extra because: A specified feature required more work than estimated Normal debugging was required Platform implementations differed A selected library proved unsuitable Store submission took more effort than anticipated 20. Developer Estimate Requirements The developer’s proposal must include: Fixed total cost Milestone schedule Estimated timeline Proposed technical stack Minimum supported iOS and Android versions Calculator integration method Local search approach Auth0 approach RSS and caching approach Push notification architecture How AFA staff will send notifications Newsletter queue approach Calendar integration method Device and QA plan Store-submission experience Warranty Recurring third-party costs All assumptions and exclusions Anything reasonably necessary to deliver the functionality above should be treated as included unless specifically excluded in the developer’s written estimate.