My Journey Bringing Mythia to the App Store
Here's what I wish I knew before launching Mythia on app stores: patience, privacy, and process matter!
This document started as notes to myself – things to do or think about. It grew into something more: insights I wish I had known before putting our game, Mythia, on app stores. This idea of helpful prior knowledge comes from Stephen Diehl's writing.
While breaking this down into multiple articles might be more personally advantageous for brand-building, and the algorithm my main goal is different. This isn't for expert mobile developers. It's for other engineers, like me, who happen to be the best person in their particular room to launch their company’s assets in the app store. You’re not a deeply experienced mobile developer. You may have a web-app wrapper tech like Capacitor and a whole lot of perseverance. Experience has to be earned somewhere. You are about to enter a season of growth. This document describes mine. These pages describe mistakes, unexpected problems, and lessons learned while releasing Mythia.
I hope my experiences can help others. If you find this useful or if you've had similar experiences, email me. If you have your own challenges or knowledge to share, please do. By working together, we can make this a better guide for the engineering community.
Executive Summary
App Store Launch: Things I Wish I Knew
Take it slow. Seriously, don't rush the app store process. Intentional choices are key. Think of the app store like a major grocery chain - you gotta convince them your product is worth shelf space.
Privacy is HUGE. Apple's privacy rules are no joke. Answer those survey questions super carefully.
In-App Purchases? Hold up. Try to get your app approved first, then add in-app purchases. Two smaller passes is better.
Explain those purchases! If you do have in-app purchases, spell out exactly what they do and how they add value for the player. Talk to the reviewers like they're a friend.
Finish all the paperwork first. Yeah, I know, feels weird for a developer, but you need all the legal stuff and bank info done before coding or nothing works right.
One App Store at a Time. Start with Apple, honestly. It's tougher, but you'll learn a lot. Then tackle Google Play.
No "Beta" Allowed. If your logo or anything says "beta," Apple will reject you. It screams "unfinished" to them.
Don't spam reviews. Every new submission resets your spot in the queue. Be patient.
OTA Updates: Be smart. If you're using over-the-air updates, make sure you know exactly which version Apple is reviewing.
EULA is Important. Link the EULA in your app description. Apple cares about this detail.
Google Play's Open Testing is LIVE. Open Testing on Google Play is not a staging area. It's the real deal. Real users will see it.
Android Signing Key is Unique. Test OAuth on both your dev builds and the Internal Testing track. Android uses different signing keys when it's live.
Share what you learn. If you mess up and figure something out, share it with the open-source communities. Help others avoid the same problems!
Use One Purchasing Project and App ID. It makes testing easier. Sandbox environments will make purchases free.
Internal Testing Messiness. Be aware that in-app purchases in Internal Testing or TestFlight builds are real purchases in the production environment. You'll need to filter them from your app analytics to be sure you are accurately interpreting business health.
Mythia is an AI-powered game where player choices drive unique, interactive narratives. It can be found on the Apple App Store, Google Play Store, and the Mythia website. Originally a Vue web application, we decided to create a mobile app to enhance user retention through easier purchasing, push notifications, and home screen presence. As a founding engineer and CTO with some prior mobile experience (including launching a free app and using Flutter), I joined Mythia. We opted for Capacitor to wrap our app, a decision made with an initial incomplete understanding of the technology. Capacitor is a framework offering components and plugins to adapt web technologies for mobile, but it requires careful selection and adaptation of plugins to fully meet an app's specific requirements, rather than being a complete out-of-the-box solution for converting web apps to mobile.
Adjust your attitude
Entering the app store ecosystem is a journey that demands patience and a strategic mindset above all else. Resist the urge to rush; every decision, every step in this process requires careful consideration. Think of it as a marathon, not a sprint. Haste can lead to oversights and ultimately prolong your journey. Embrace the time it takes to refine your app and its presentation. In retrospect, the initial rejection of our first build proved to be a blessing in disguise. It forced a critical self-assessment and spurred significant improvements.
It's vital to understand that gaining a presence on the app store is not an automatic entitlement. Drawing a parallel to the physical retail world, the app store functions much like a major grocery chain. They wield significant market influence, and their digital "shelf space" represents prime real estate in the mobile marketplace. As a developer, you are essentially vying for the attention of these "store owners," needing to demonstrate that your application is a valuable addition to their platform, worthy of the visibility it provides.
When you've poured your heart and soul into developing your app, it's natural to be blind to its imperfections. However, achieving app store approval necessitates a degree of ruthless self-critique. You must be willing to objectively evaluate your creation, identify its shortcomings – to "call your baby ugly" if necessary – and dedicate yourself to making the necessary improvements. This willingness to iterate and enhance your product is paramount to success. Remember, a measured and thoughtful approach, characterized by calm deliberation, will ultimately lead you to the finish line more efficiently than any hurried attempt.
Furthermore, meticulous attention to privacy regulations is non-negotiable. The App Store's policies in this domain are absolute and must be adhered to without exception. When completing the privacy-related survey questions during the submission process, ensure that your responses are accurate, comprehensive, and reflect a thorough understanding of the requirements. Failure to address these aspects diligently can lead to significant delays, misclassification of your app’s age level or outright rejection. Treat the app store submission process with the respect and thoroughness it deserves, recognizing it as a critical gateway to reaching your target audience.
In App Purchases
Submitting a game to the app store is a significant milestone, fraught with potential pitfalls. Our experience bringing Mythia to the app store yielded several key learnings, particularly around in-app purchases and the review process. This document elaborates on those experiences to help guide fellow developers.The Strategic Approach to In-App Purchases: Review First, Monetize Later
A crucial takeaway from our journey with Mythia was the importance of separating the initial app review from the implementation of in-app purchases. We were in a phase of rapid development, still seeking product-market fit for our web application, which continued in parallel with the app store submission process. Consequently, we found ourselves developing a micro-purchase strategy before our initial app review was complete.
This approach proved more challenging than anticipated. We were forced with a choice: maintain an older build against outdated APIs solely for the purpose of passing the initial review or keep the under review version in sync. The effort required to keep this separate version functional outweighed the benefits compared to simply upgrading the reviewed app to align with our ongoing development.
However, we strongly advise attempting to pass the initial app review before integrating any in-app purchase functionality. If this isn't feasible for your project, aim to introduce in-app purchases incrementally. Get one purchase type approved first; adding subsequent purchases of the same type is generally a more straightforward process.
For those who, like us at Mythia, already have an app with existing in-app purchases, the key to navigating the review process lies in clear and comprehensive communication.
Communicating the Value of Your In-App Purchases
Carefully articulate the purpose and value proposition of each in-app purchase. Your explanation should clearly detail how the purchase relates to the core functionality of your application and, most importantly, how it enhances the player or user experience.
The App Store guidelines repeatedly emphasize that both the app itself and any included in-app purchases must provide genuine value to users. Your explanations are your opportunity to explicitly justify this value to the review team.
Remember that the reviewers are not adversaries but rather colleagues who want to see your product succeed. Frame your explanations in a friendly and collaborative tone. They are there to ensure the quality of the apps on their platform, which ultimately benefits both developers and users. By clearly demonstrating the value your in-app purchases offer, you are working with the reviewer towards a successful launch.
The paperwork blocks the coding
For developers accustomed to diving straight into code, the necessity of completing all administrative paperwork before implementation might seem counterintuitive. However, our experience with the App Store unequivocally demonstrates its critical importance.
The App Store will not deliver your configured purchasable items via API calls if the corresponding paperwork is incomplete. Furthermore, the system provides no explicit error message to indicate this oversight. This lack of feedback can lead to significant frustration and wasted effort.
We meticulously configured all the technical aspects – webhooks, product imports into RevenueCat, and even successful product purchases via the RevenueCat API. However, when the RevenueCat API attempted to exchange these purchases for the native store items, the returned array of products was consistently empty. The root cause? I hadn’t completed the Paid App agreement.
Therefore, it is paramount to finalize all required paperwork and banking information for both app stores before writing a single line of code related to in-app purchases. Be aware that it also takes some time for the relevant APIs to fully "unlock" after the paperwork is submitted and approved. Completing this step upfront will save you significant time and frustration down the line, ensuring a smoother integration and testing process for your in-app purchase functionality.
Phased App Store Reviews
Our journey to bring Mythia to mobile began with a deliberate decision: to tackle one app store at a time, prioritizing Apple's App Store initially. This might seem counterintuitive, especially given the Android market's size, but we believed that navigating Apple's more stringent review process first would ultimately lead to a more robust and polished app. In retrospect, this proved to be a valuable strategy.
The complexity of the Apple App Store review process pushed us to refine Mythia to a higher standard early on. We anticipated that successfully launching on Apple would, in turn, streamline our eventual entry into the Google Play Store. Had we started with Google, we worried that the relative ease of entry might have given us a premature sense of accomplishment, potentially masking underlying issues that Apple's review would later flag, leading to more significant rework down the line.
Our experience with Apple involved a multi-stage submission process. It took us four distinct review cycles to finally receive approval. Each rejection, while initially disheartening, provided crucial feedback that allowed us to identify and address shortcomings in our app, from minor policy violations to more significant user experience considerations. By the third round, the feedback indicated a more extensive review period. Rather than remain idle, we strategically decided to begin the groundwork for our Google Play Store submission in parallel. This concurrent effort was primarily focused on ensuring our in-app purchase implementation adhered to Google's policies, allowing us to make progress on one front while awaiting feedback on the other.
This experience reinforced a key learning: focusing intently on a single app store at the outset is paramount. While it's crucial to remain mindful of the requirements of other platforms to avoid future roadblocks, dedicating your primary resources to achieving approval on one store first is the most efficient path. Understand the specific guidelines and nuances of your initial target platform and iterate diligently based on their feedback. Once you've successfully navigated the review process for one store, you can then leverage that experience and a more refined app to tackle subsequent platforms with greater confidence and efficiency. This phased approach minimizes distractions and allows for a more concentrated effort, ultimately increasing your chances of successful launches across multiple app stores.
Navigating the Google Play Console
The journey of bringing our game, Mythia, to the Google Play Store has been an eye-opening experience, filled with valuable, sometimes harsh, lessons learned along the way. One particular revelation stands out, a stark warning for any developer venturing into the Android ecosystem: The Google Play Console is a deceptively complex environment, where seemingly innocuous actions can have significant real-world consequences.
My initial approach to deploying Mythia involved leveraging the testing tracks, using the “promote build” to move from app sharing to internal testing. In my naiveté, I envisioned this as a gradual progression towards a full production release – a safe space to gather feedback and iterate before exposing the game to a wider audience. This assumption, as I quickly discovered, was fundamentally flawed. I had assumed that Open testing was like Apple’s beta testing, and without assigning anyone to the group, it’d be private.
The reality is this: The Open Testing track IS THE REAL PLAY STORE. Let me reiterate this with the emphasis it deserves: DO NOT DEPLOY TO OPEN TESTING UNLESS YOU ARE ABSOLUTELY CERTAIN YOUR APP IS READY FOR PUBLIC CONSUMPTION.
The moment your app is released to the open testing track, it becomes discoverable to real users with real Android devices. These are not internal testers who understand the nuances of a pre-release build. These are everyday users browsing the Play Store, potentially searching for new games to download. They will interact with your app as if it were a final product, and their experience – be it positive or negative – will be genuine and unfiltered.
Deploying a buggy, incomplete, or otherwise unprepared build to open testing can lead to a multitude of issues:
Negative Reviews and Ratings: Early negative feedback can significantly impact your app's overall rating and reputation, making it harder to attract users once you officially launch.
Uninstalls: A poor initial experience can lead to immediate uninstalls, and it's often difficult to win back users who have already formed a negative impression.
Public Perception: Your open testing track effectively becomes a public preview of your game. A flawed preview can damage the perception of your game before it even has a chance to succeed.
Irreversible Actions: Unlike internal testing environments, actions taken on the open testing track have real-world implications that cannot be easily undone.
My own experience served as a stark reminder of this crucial distinction. While the testing tracks are invaluable tools for gathering feedback, it's imperative to understand the specific purpose and audience of each. The open testing track is not a sandbox; it's a live environment. Treat it with the respect and caution you would a full production release. Ensure your app is thoroughly tested internally, and consider utilizing closed or internal testing tracks for earlier stages of feedback and iteration. Only when you are confident that your app is ready for public eyes should you venture into the open testing track. This seemingly small detail can be the difference between a successful launch and a challenging uphill battle in the competitive world of the Google Play Store.
OAuth depends on The Google Play signing key
Our experience launching Mythia on the app stores provided invaluable lessons, particularly concerning the nuances of different deployment environments and the importance of contributing back to the open-source community.
One critical learning experience revolved around OAuth integration. We diligently tested our OAuth implementation in our lower development environments. However, we encountered a significant issue upon initial launch on the Google Play Store: our OAuth authentication failed. This was due to Android utilizing distinct signing keys for applications deployed directly from the Play Store compared to testing builds. This discrepancy, which we had overlooked, prevented users from authenticating correctly.
This experience underscored the absolute necessity of rigorously testing all critical functionalities, especially authentication mechanisms, across every possible deployment environment, including the final production build distributed through the app stores. On google Internal Testing Track and Testflight on Apple is the means to test that The subtle differences in build processes and signing keys between testing and production can lead to unexpected and potentially critical failures.
Beyond addressing our own challenges, our journey highlighted the reciprocal nature of the open-source software ecosystem. We heavily benefited from numerous open-source libraries and tools in the development of Mythia. Recognizing this, we made a conscious effort to contribute back to these communities.
One tangible way we did this was by submitting documentation updates. Reflecting on our OAuth mishap, we realized that clearer documentation regarding the different signing key behavior in Android could have potentially saved us, and countless other developers, from experiencing the same issue. We proactively contributed these insights back to the relevant open-source projects, aiming to prevent others from stumbling over the same hurdles.
While encountering and resolving such issues, especially when they manifest in production, can be initially embarrassing, it's crucial to view these moments as opportunities for collective growth. By openly sharing our mistakes and the lessons learned, we can collectively raise the quality and reliability of the open-source software that underpins so much of our industry. Contributing these "gotchas" back to the documentation ensures that the knowledge gained from our experiences benefits the entire community, ultimately leading to better and more robust applications for everyone. Our commitment to contributing back, even when it stems from our own errors, reflects a belief in the power of shared learning and the continuous improvement of our technological landscape.
Use 1 Purchasing Project and App Id
Mythia adopted RevenueCat’s recommendation of a single project for in-app purchase (IAP) testing by strategically leveraging the production application identifier from the initial stages of development. This seemingly unconventional approach yielded significant advantages in terms of efficiency and simplicity. The core principle behind this strategy lies in the intelligent handling of sandbox environments by both the app stores (Apple App Store and Google Play Store) and RevenueCat, Mythia's chosen subscription management platform. These platforms discern development builds from production releases. Consequently, when a development build, intended for testing, interacts with the production app ID, the app stores and RevenueCat automatically route purchase requests to their respective sandbox environments.
In these sandbox environments, actual monetary transactions are circumvented, allowing for comprehensive testing of the complete subscription lifecycle – from initial purchase and renewals to cancellations and expirations – without incurring any real charges. This facilitated rigorous and risk-free testing of various subscription scenarios and edge cases.
The utilization of a single, production-grade app ID across all development stages offered a substantial simplification of backend configurations. Instead of managing separate sets of API keys and webhook endpoints for sandbox and production environments, Mythia maintained a unified configuration within RevenueCat. The platform intelligently differentiated between sandbox and production transactions based on the build type, ensuring that data and events were routed and processed accordingly. This eliminated the complexity and potential for errors associated with managing multiple sets of credentials and configurations.
Furthermore, Mythia effectively utilized Capacitor's environment variable configuration to maintain a single listing on the app stores. This approach allowed staging or internal testing versions of the application to be deployed from the same codebase as the production version. By configuring environment variables within Capacitor, these staging builds could be directed to connect with lower-level backend environments or specific test instances of supporting services, ensuring isolation and preventing unintended interactions with the live production environment.
While the unified app ID strategy proved largely successful, a minor challenge was encountered during Internal Testing (Google Play Store) and TestFlight (Apple App Store) phases. In these specific distribution channels, test purchases were inadvertently processed as live production transactions. To mitigate the impact on production analytics, Mythia implemented a manual tracking system. This system was used to identify and filter out the test purchase data from Amplitude, the company's analytics platform, ensuring the accuracy and integrity of production usage metrics.
Despite this necessary manual step for specific testing channels, the overarching benefits of adopting a unified app ID and the resulting simplification of the in-app purchase testing process were deemed considerably worthwhile. The approach significantly reduced the overhead associated with managing multiple app IDs and backend configurations, enabled more thorough and cost-effective testing of subscription functionalities, and ultimately contributed to a more efficient and reliable application development lifecycle.
Small Recommendations
Remove mention of Beta
Apple rejected our initial review due to an "App completeness" issue. This was because our logo contained the word "beta." To avoid this, remove "Beta" from all aspects of your app, especially the logo. Apple considers "beta" to signify an unfinished product.
Manage your review pipeline
To expedite App Store review, avoid submitting multiple builds. Each new submission restarts your place in the review queue.
Design OTA update carefully
When submitting your app for Apple review, ensure you're aware of the exact application version under scrutiny. If employing Over-The-Air (OTA) updates, implement a system that isolates builds intended for Apple's review process. While this aligns with standard delivery management, it can easily be overlooked in a dynamic startup environment with numerous moving components. We adopted a strategy known as versioned channels, detailed by the CapAwesome team. Additionally, remember that each plugin impacts native code, necessitating app reviews for every new plugin integration. Consequently, careful management of these considerations is essential.
Link your or apple’s stock EULA in the app description
The feedback regarding EULA documentation was unclear, “EULA missing from app metadata”. It was unclear what app metadata mean. The resolution however was trivial:
Add EULA inside the app.
Include EULA in the App Description.
Reference: https://maxmannstein.com/index.php/where-to-put-the-eula-for-ios-apps-implementing-subscriptions/