Vibe coding apps is one things, but what about deploying and distributing them? That still requires some elbow grease, and I’ve described my experiences with both Apple and Google below for my first apps in each platform.

(I’m writing this from the perspective of someone familiar with coding primarily through bash scripts, JavaScript, Python, and various other languages, but with no prior IDE or mobile app development experience when I got started, as I typically work in vim through the terminal. I was brand new to IDEs and app development for both iOS and Android when I got started. For context, I have an iOS personal device.)

Being new to iOS app development

First, some notes on iOS development. If you only want to test your app on your own phone, it’s free. You can build the app in XCode and with a cord, deploy it directly on your phone. However, if you wish to distribute apps via TestFlight (digitally) to yourself or other users, Apple requires a paid developer account at $99 per year. (This cost can be annoying for people working on free apps who are doing this as not-a-business). Initially, figuring out the process to move an app from Xcode to TestFlight or the App Store is somewhat challenging. However, once you understand that archiving the app opens a popup to distribute it, the process becomes seamless. Sometimes there are errors if Apple has new development agreements for you to sign in the web interface, but the errors from the process just say your account is wrong. (So check the developer page in your account for things to sign, then go try again once you’ve done that.) TestFlight itself is intuitive even for newcomers, whether that is yourself or a friend or colleague you ask to test your app.

Submitting an app to the App Store through the web interface is relatively straightforward. Once you’ve got your app into TestFlight, you can go to app distribution, and create a version and listing for your app and add the build you put into TestFlight. Note that Apple is particular about promotional app screenshots and requires specific image sizes. Although there are free web-based tools to generate these images from your screenshots, if you use a tool without an account login, it becomes difficult to replicate the exact layout later. To simplify updates, I eventually switched to creating visuals manually using PowerPoint. This method made updating images easier when I had design changes to showcase, making me more likely to keep visuals current. Remember, you must generate screenshots for both iPhone and iPad, so don’t neglect testing your app on iPad, even if usage might seem minimal.

When submitting an app for the first time, the review process can take several days before beginning. My initial submission encountered bugs discovered by the reviewer and was rejected. After fixing the issues and resubmitting, the process was straightforward and quicker than expected. Subsequent submissions for new versions have been faster than the very first review (usually 1-3 days max, sometimes same-day), and evaluation by App Store reviewers seems more minimal for revisions versus new apps.

The main challenge I have faced with App Store reviews involved my second app, Carb Pilot. I had integrated an AI meal estimation feature into PERT Pilot and created Carb Pilot specifically for AI-based meal estimation and custom macronutrient tracking. Same feature, but plucked out to its own app. While this feature was approved swiftly in PERT Pilot as an app revision, Carb Pilot repeatedly faced rejections due to the reviewer testing it with non-food items. Same code as PERT Pilot, but obviously a different reviewer and this was the first version submitted. Eventually, I implemented enough additional error handling to ensure the user (or reviewer, in this case) entered valid meal information, including a meal name and a relevant description. If incorrect data was entered (identified by the API returning zero macronutrient counts), the app would alert users. After addressing these edge cases through several rounds of revisions, the app was finally approved. It might have been faster with a different reviewer, but it did ultimately make the app more resilient to unintended or unexpected user inputs.

Other than this instance, submitting to the App Store was straightforward, and it was always clear at what stage the process was, and the reviewer feedback was reasonable.

(Note that some features like HealthKit or audio have to be tested on physical devices, because these features aren’t available in the simulator, so depending on your app functionality, you’ll want to test both with the simulator and with physical iOS devices to test those. Otherwise, you don’t have to have access to test on a physical device.)

Being new to Android app development

In contrast, developing for Android was more challenging. I decided to create an Android version of PERT Pilot after receiving several requests. However, this effort took nearly two years and four separate attempts to even get a test version built. I flopped at the same stage three times in a row, even with LLM (AI) assistance in trying to debug the problem.

Despite assistance from language models (LLMs), I initially struggled to create a functional Android app from scratch. Android Studio uses multiple nested folder structures with Kotlin (.kt) files and separate XML files. The XML files handle layout design, while Kotlin files manage functionality and logic, unlike iOS development, which primarily consolidates both into fewer files or at least consistently uses a single language. Determining when and where to code specific features was confusing. (This is probably easier in 2025 with the advent of agent and IDE-integrated LLM tools! My attempts were with chat-based LLMs that could not access my code directly or see my IDE, circa 2023 and 2024.)

Additionally, Android development involves a project-wide “gradle” file that handles various settings. Changes made to this file require manually triggering a synchronization process. Experienced Android developers might find this trivial, but it is unintuitive for newcomers to locate both the synchronization warnings and the sync button. If synchronization isn’t performed, changes cannot be tested, causing blocks in development.

Dependency management also posed difficulties, and that plus the gradle confusion is what caused my issues on three different attempts. Initially, dependencies provided by the LLM were formatted incorrectly, breaking the build. Eventually (fourth time was the charm!), I discovered there are two separate gradle files, and pasting dependencies correctly and synchronizing appropriately resolved these issues. While partly user error (I kept thrashing around with the LLM trying to solve the dependency formatting, and finally on the fourth attempt realized it was giving me a language/formatting approach that was a different language than the default Android Studio gradle file, even though I had set up Android Studio’s project to match the LLM approach. It was like giving Android Studio Chinese characters to work with when it was expecting French), this issue significantly impacted my development experience, and it was not intuitive to resolve within Android Studio even with LLM help. But I finally got past that to a basic working prototype that could build in the simulator!

I know Android has different features than iOS, so I then had to do some research to figure out what gestures were different (since I’m not an Android user), as well as user research. We switched from swiping to long pressing on things to show menu options for repeat/edit/deleting meals, etc. That was pretty easy to swap out, as were most of the other cosmetic aspects of building PERT Pilot for Android.

Most of the heartache came down to the setup of the project and then the exporting and deploying to get it to the Play Store for testing and distribution.

Setting up a Google Play developer account was quick and straightforward, despite needing to upload identification documents for approval, which took a day to get verified. There’s a one-time cost ($25) for creating the development account, that’s a lot cheaper than the yearly fee for Apple ($99/year). But remember, above and below, that you’re paying with your time as opposed to money, in terms of a less intuitive IDE and web interface for moving forward with testing and deploying to production.

Also, you have to have hands-on access to a physical Android device. I have an old phone that I was able to use for this purpose. You only have to do this once during the account creation/approval process, so you may be able to use a friend’s device (involves scanning QR code and being logged in), but this is a little bit of a pain if you don’t have a modern physical Android device.

I found navigating the Play Store developer console more complicated than Apple’s, specifically when determining the correct processes for uploading test versions and managing testers. Google requires at least 12 users over a two-week testing period before allowing production access. Interestingly, it’s apparently pretty common to get denied production access even after you have 12 users, the minimum stated. It’s probably some secret requirement about app use frequency, although they didn’t say that. The reason for rejection was uninformative. Once denied, you then have a mandatory 14 day wait period before you can apply again. I did some research and found that it’s probably because they want a lot of active use in that time frame. Instead of chasing other testers (people who would test for the sake of testing but not be people with EPI), I waited the 14 days and applied again and made it clear that people wouldn’t be using the app every day, and otherwise left my answers the same…and this time lucked into approval. This meant I was allowed to submit for review for production access to the Play Store. I submitted….and was rejected, because there are rules that medical and medical education apps can only be distributed by developers tied to organizations that have a business number and have been approved. What?!

Apparently Google has a policy that medical “education” apps must be distributed by organizations with approved business credentials. The screenshots sent back to me seem to be flagging on the button I had on the home screen that described PERT and dosing PERT and information about the app. I am an individual (not an organization or a nonprofit or a company) and I’m making this app available for free to help people, so I didn’t want to have to go chase a nonprofit who might have android developer credentials to tie my app to.

What I tried next was removing the button with the ‘education’ info, changing the tags on my app to fall under health & fitness rather than ‘medical’, and resubmitting. No other changes.

This time…it was accepted!

Phew.

–

TL;DR: as more and more people are going to vibe code their way to having Android and/or iOS apps, it’s very feasible for people with less experience to do both and to distribute apps on both platforms (iOS App Store and Google Play Store for Android). However, there’s an up front higher cost to iOS ($99/year) but a slightly easier, more intuitive experience for deploying your apps and getting them reviewed and approved. Conversely, Android development, despite its lower entry cost ($25 once), involves navigating a more complicated development environment, less intuitive deployment processes, and opaque requirements for app approval. You pay with your time, but if you plan to eventually build multiple apps, once you figure it out you can repeat the process more easily. Both are viable paths for app distribution if you’re building iOS and Android apps in the LLM-era of assisted coding, but don’t be surprised if you hit bumps in the road for deploying for testing or production.

Which should you choose for your first app, iOS or Android? It depends on if you have a fondness for either iOS or Android ecosystem; if one is closer to development languages you already know; or if one is easier to integrate/work with your LLM of choice. (I now have both working with Cursor and both also can be pulled into the ChatGPT app). Cost may be an issue, if $99/year is out of reach as a recurring cost, but keep in mind you’ll pay with your time for Android development even though it’s a $25 single time user account setup fee for developers. You also may want to think about whether your first app is a one-off or if you think you might do more apps in the future, which may change the context for paying the Apple developer fee yearly. Given the requirements to test with a certain number of users for Play Store access, it’s easier to go from testing to production/store publication on Apple than it is for Google, which might factor into subsequent app and platform decisions, too.

One of the things I wish people would consider more often when thinking about AI is how they can use it to scale themselves. What are some time-consuming things that they currently have to do themselves that AI could do for them to streamline their output and increase their productivity? Productivity for giving them more time to do the things only they can do, the things they want to do, or the things they love to do. (And to help stop procrastinating on things they have to do.)

I have a habit of trying to scale myself. These days, it’s often related to EPI (exocrine pancreatic insufficiency, which some areas of the world know by the acronym PEI). I developed a strong knowledge base first from personal experience, then by doing research – including a systematic review where I read hundreds, plural, of research papers on key topics related to design protocols and guidelines. As a result of both personal and research experience, I have a lot of knowledge. It gets tapped almost daily in the EPI support groups that I’m a part of.

Whenever I notice myself answering the same question repeatedly, I make a mental note of it. Eventually, if a topic comes up often enough, I turn my response into a blog post. This way, I can provide a well-structured, comprehensive answer with more time and context than a quick comment on social media allows – and with the ability to give the same, high quality answer to multiple people (and in some cases, hundreds or thousands of people rather than the few who might see the comment buried in a response thread).

A few examples of this include:

• Explaining why fecal elastase test results change over time; why they’re not perfect; what being above or below certain cutoffs mean; why you don’t need to stop taking enzymes for an elastase test; why elastase test isn’t directly impacted by taking enzymes; why elastase isn’t used to determine how much enzymes you need or whether or not enzymes are ‘working for you’. All that in one post (here) with a lot of context and resources including links to medical literature to back all that up, which is hard to do well as one-off facebook comments and easier to do in a blog post format.
• A guide to discussing enzyme dosing starting guidelines and best practices for titrating (increasing) your enzyme dose, including resources (again, medical literature) to share with your doctor to help inform your discussions
• Information on an approach to record what you’re eating, and why, in order to adjust and optimize your enzyme dosing, because enzymes have to (should) be dosed in relationship to the food consumed.

One of my favorite things with this approach is then seeing other people begin to share the links to my longer-form content to help answer common questions. By writing things down in a shareable way, it also enables and supports other people to scale your work by sharing it easily. This has started to happen more and more with the elastase blog post, in part because there are so few resources that cover this information all in one place.

For me, I lean toward writing, but for other people that could be videos, podcast/audio recording, or other formats that can capture things you know and make them shareable, thus scaling yourself.

For me, this approach of “scaling myself” and thinking about longer form content to post online instead of re-typing similar answers over and over again isn’t unique to EPI.

I have been doing this for over a decade. I developed this pattern early after we developed and shared OpenAPS (the first open source automated insulin delivery algorithm) with the world. Early on, I found myself answering the same technical questions repeatedly in online discussions with the same answers. Typing out explanations on my phone was inefficient, and if one person had a question, others likely had the same one. Instead of repeating myself, I took the time to document answers. I would often pause, write up the information in the documentation, and share that instead. This made it easier and quicker to go find and share a link instead of retyping responses, and it also took less time, so I was willing to do it more quickly than if I had to delay what I was doing in real life in order to type out a long yet already-answered question. Over time, I had to do less one-off typing on my phone (and could save that time and energy for true, one-off unique questions) and could share links with a lot more information more easily.

How do I use AI to scale this type of work?

A lot of the above tasks are related to writing. There are different ways you can use AI for writing, without having it write something completely. You can give it notes – whether you type or voice dictate them – and have it clean up your notes, so you can focus on thinking and not about typing or fixing typos that break your flow. You can have it convert the notes into full sentences. You can ask it to write a paragraph or an article based on the notes. You can ask it to suggest wording for a particular sentence you want to clarify for your audience.

If you think about the AI as an intern and/or a partner/collaborator who you would ask to review or edit for you, you’ll likely find even more ways to integrate AI into different parts of your writing process, even if it’s not doing the full writing for you.

I have also tried to task the AI with writing for me, with mixed results. This doesn’t mean I don’t use it, but I’ve been practicing and learning where it generates usable content and where it doesn’t.

A lot of it depends on the prompt and the topic (as much as it does the output in terms of style, length, intended audience etc).

If it’s a topic that’s “known”, it can write more content that I can take and edit and transform, as opposed to when I am trying to write about a concept that is far from the current knowledge base. (I mean far for both humans and of AI – a lot of my work is bleeding edge, pushing fields towards new developments and leading humans there.) Sometimes I ask it to write something and end up using none of the content, but by saying “ugh no” my brain has jumped to saying to myself “it should really say…” and I am able to more quickly springboard into manually writing the content I was previously slow on. In other words, it can be a brainstorming tool in the opposite sense, showing me what I do not want to say on a topic! And on some of my frontier/bleeding edge topics, it reflects what is commonly ‘known’ and when what is known is now wrong (example, as always, of how it’s commonly incorrectly reported that chronic pancreatitis is the most common cause of EPI), it helps me more clearly distinguish the new content from the old, wrong, or misinformed.

(Also, it’s worth reminding you what I have to remind myself, that AI is changing constantly and new tools override what is known about what tasks do and don’t do well! For example, in between writing this and posting it, OpenAI released GPT4.5, which is reportedly better at writing-related tasks than GPT-4o and other older models. I’ll have to test it and see if that’s true and for what kinds of writing tasks!)

This isn’t the only way you can scale yourself with AI, though. Scaling yourself doesn’t have to be limited to writing and documentation style tasks. AI and other tools can help with many tasks (more examples here and here), such as:

• Cleaning and transforming data into different formats
• Converting a CSV file into a more readable table
• Writing code to automate tedious data processing
• Drafting plain-language instructions for engineers or programmers
• Checking whether instructions or explanations are clear and understandable, and identifying any gaps in logic that you missed on your first pass

By leveraging AI and other automation tools, you can free up time and energy for higher-value work: the things you are uniquely suited to do in the world, and the things that you want or love to do. And do them more easily!

Pro tip: if you find yourself procrastinating a task, this may be a good sign that you could use AI for some of it. 

I’m trying to use noticing procrastination as a trigger for considering AI for a task.

An example of this is an upcoming post with a bunch of math and meaty cost analysis that I originally did by hand. I needed (wanted) to re-do these estimates with different numbers, but procrastinated a bit because having to carefully re-do all the estimates and replace them throughout the blog post seemed tedious, so my brain wanted to procrastinate. So, I took the blog post and dumped it in with a prompt asking it to write Jupyter Notebook code to replicate the analyses explained via the plain language post, with the ability to adjust all input variables and see the results in a table so I could compare the original and updated numbers. It took less than 1 minute to generate this code and about 5 minutes for me to copy/paste, update the numbers, run it, and evaluate the output and decide what to update in the post. Manually, this would’ve taken 30-60 minutes due to needing to check my work manually and trace it throughout the post. Instead, this automated the tedious bit and will result in this new post coming out next week rather than weeks from now (read about it here – it’s an analysis on how cost-effect Life for a Child is, a charity supporting people living with diabetes in low- and middle-income countries that can use your help to save lives.)

I encourage you to think about scaling yourself and identifying a task or series of tasks where you can get in the habit of leveraging these tools to do so. Like most things, the first time or two might take a little more time. But once you figure out what tasks or projects are suited for this, the time savings escalate. Just like learning how to use any new software, tool, or approach. A little bit of invested time up front will likely save you a lot of time in the future.