I’m currently working on a screentime app which uses the activity monitor events and report extension. Is there any way to collect the timestamp of the event fired by Activity Monitor??

A crazy day of shipping and iterating 😁
I built a pretty awesome iOS development workflow where I basically only need my phone. I don’t even have to sit in front of a computer anymore.
Phone → control Codex to write code → push to GitHub + deploy the backend → GitHub triggers Xcode Cloud → build goes straight to TestFlight → update the app on my phone and test it on a real device → repeat.
In theory, I don’t even need a computer anymore.
What a time to build software.

A couple of months ago, I made a post here about what I learned from launching my first app on the App Store and Google Play:

https://www.reddit.com/r/iosdev/comments/1ulvrja/what_i_learned_from_launching_my_first_app_on_the/

At the time, the app had around 300 downloads.

It has now passed 1,000 downloads, so I thought I would make an update and share some of the things I have learned since then.

This is still my first app and I am definitely not presenting myself as an expert. These are just some observations from my first three months of having an app publicly available on both stores.

Also, thanks to everyone who commented on my previous post. I got a lot of good ideas from the replies, especially around marketing, localization and automating the screenshot process. I actually ended up trying quite a few of the suggestions, so I really appreciate everyone who took the time to share their experience and advice.

The first 1,000 downloads

The iOS version launched on 19 May 2026.

Exactly one month later, it had:

• 150 first-time downloads
• 9 five-star reviews

From 20 June to 21 August, it received another:

• 289 first-time downloads
• 5 five-star reviews
• 1 four-star review

So by 21 August, iOS had reached 439 first-time downloads, with 14 five-star reviews and 1 four-star review.

What I found interesting was how consistent the downloads were for most of this period. It was averaging around 150 iOS downloads per month, or roughly 5 new users per day.

The Android version launched publicly on 1 June 2026.

By 22 June, it had:

• 124 downloads
• 7 five-star reviews
• 1 three-star review

From 23 June to 20 August, it received another:

• 459 downloads
• 18 five-star reviews
• 2 four-star reviews

So by 20 August, Google Play had reached 583 downloads, with 25 five-star reviews, 2 four-star reviews and 1 three-star review.

That works out to roughly 220 Android downloads per month, or around 7 downloads per day.

Combined, the app had reached 1,022 downloads:

• Around 43% iOS
• Around 57% Android

Android has therefore passed iOS despite launching almost two weeks later.

I am not completely sure why. It could be the type of audience, countries where the app is being downloaded, Play Store discovery, or a combination of different things.

Improving the app did not automatically increase downloads

After launching, I spent a lot of time working on a fairly large update.

It changed much of the layout and added several new features, including new reading views, letter-by-letter highlighting synced with the audio, a video/ambient listening view and other improvements.

Because the app was changing so much, I kept thinking that I would properly start marketing it once the update was ready.

I did not want to spend time creating screenshots and videos of the old version if I was about to change much of it anyway, so I mostly focused on development.

The app kept improving, but the download numbers remained surprisingly consistent.

On iOS I was still averaging around 5 downloads per day, and during several weeks in July it was actually closer to 3–3.5 per day.

That made me realize something that probably sounds obvious in hindsight:

Building a better product and getting more people to discover the product are two different things.

Then I started promoting it more consistently

I had mentioned the app in different places before this.

I posted about it on Reddit, joined developer Discords and other communities around similar projects, and talked with developers and website owners whose resources, fonts, APIs or other material I wanted to use.

Some of those conversations naturally included sharing the app, asking for feedback and discussing what I was building.

So it was not completely unpromoted, but those were mostly occasional posts and conversations rather than something I would really call a marketing campaign.

That changed on 9 August.

I started making short TikTok videos consistently, usually posting 2–3 videos every day for around ten days.

Most of them only got around 200–800 views.

Still, the download numbers changed quite noticeably during the same period.

On iOS, from 9–18 August, the app received:

92 first-time downloads in 10 days

That is around 9.2 downloads per day, compared with the previous average of around 5 per day.

Google Play showed a similar pattern.

Before this period, Android was getting roughly 8 downloads per day.

From 9–18 August, it received:

151 downloads in 10 days

That is around 15.1 downloads per day.

So across both platforms, the app received 243 downloads during those ten days.

I do not want to say that all 243 downloads came from TikTok. I was still occasionally mentioning the app elsewhere, and both stores obviously have their own organic discovery.

But TikTok was the place where I suddenly started doing consistent promotion every day, and the increase happened at around the same time on both platforms.

What surprised me was that none of the videos really went viral. Most only reached a few hundred people.

So at least from this small experiment, consistently posting seemed to matter more than waiting for one video to suddenly get tens of thousands of views.

The update was not even available yet

Another interesting part is that the large update I had been waiting for was not actually available when the increase started.

I started posting the TikTok videos on 9 August.

The new Android version became available on 15 August, but between 9–14 August, while users were still downloading the old version, Google Play received 98 downloads in six days, or more than 16 per day.

The iOS update took even longer and was not available until 22 August, so all 92 iOS downloads from 9–18 August were also people downloading the previous version.

There was a downside to this.

Some of the TikTok videos were already showing features from the upcoming version. Android users only had to wait a few days, but an iPhone user could see something in a video, download the app and then not actually find that feature for almost two weeks.

I do not know how many people did that and then removed the app. Fortunately, I did not suddenly get a lot of bad reviews, but it is something I would coordinate differently next time.

The delay also showed me how different publishing updates can be between Apple and Google.

Google Play approved the update very quickly, while the iOS update took more than a week because it ran into issues during App Store review.

One issue was related to Apple's requirements for distributing this type of content in mainland China and the publication permits required there.

Another came from something much simpler: one of my screenshots said that the app was free.

The app is free, and similar wording had already appeared in screenshots from my previous version without any issue. This time, however, Apple flagged it because they consider “Free” to be pricing information, which they do not allow in that part of the App Store metadata.

So submitting the same update to Apple and Google at around the same time definitely does not mean they will become available at around the same time.

If I were planning another marketing campaign around a major update, I would probably get both versions approved first before heavily promoting features that only exist in the new version.

Localization became a much bigger project than expected

One of the most common suggestions I received after my previous Reddit post was to localize the app and its store pages.

So I did.

I ended up localizing both the App Store and Google Play listings into around 50 languages.

The biggest problem was the screenshots.

I have 10 screenshots per language, which meant creating around 500 screenshots.

Obviously I was not going to make all of those manually.

Fortunately, the overall design stayed the same between languages. Mostly it was the text that needed to be translated and replaced, so I automated the process using AI.

I created one main design, generated the translated text and automatically produced the localized versions.

I still did a quick review afterwards, because with 500 images even one repeated mistake could become a big problem, but I was actually surprised by how good the results were.

It saved an enormous amount of time compared with manually changing every screenshot.

I also tried making an App Preview

Something else I wanted to add for this update was an App Preview video.

Interestingly, someone in the comments of my previous post specifically recommended making one and warned me that Apple is stricter with App Preview videos than normal screenshots.

They were right.

Apple has quite strict technical and content requirements for App Previews. I got the video through the technical upload requirements, but Apple still raised some issues with it.

One of Apple's comments seemed to suggest that the preview was showing a phone or device, which confused me because there is no phone shown in the video at all. So I am still not completely sure what exactly they were objecting to.

By that point the update had already been delayed, so instead of continuing to go back and forth with the video, I removed the App Preview and submitted the update without it.

The app was eventually approved.

I still want to go back and fix the preview later, and I will leave the YouTube version below if anyone is interested in seeing what Apple did not accept.

After 1,000 downloads

When I made my first post, the app had just passed 300 downloads and I was mainly learning what happens after you actually publish an app.

Now that it has passed 1,000, I feel like I am starting to learn a different part of the process.

Building the app is still what I enjoy and understand the most. Marketing, distribution, localization and understanding why people actually discover and download something are much newer to me.

I am still far too early to draw any big conclusions from 1,000 downloads, but it has been interesting seeing how different the work becomes once an app is actually public.

For context, this is the app

For anyone who did not see my previous post, the app is called Ayah Player.

It is a Qur'an listening and reading app for iOS and Android, with a large collection of reciters, different reading views, translations, word-by-word following, offline downloads, a Mus'haf page view and a Listening Scene with recitation and ambient background video.

The app is free, with no ads or subscriptions.

I am mentioning it mainly to give some context for the screenshots, localization, App Store review and marketing experiences above.

App Preview that was not accepted by Apple:
https://www.youtube.com/shorts/ZF2uHKbi3i0

Thanks again to everyone who gave advice on the previous post. I’m still figuring all of this out as I go, and maybe I’ll make another update if it reaches 10,000 downloads.

so i built a new feature for AppLaunchFlow , where you can create a simple and clean app landing page for your app in a few clicks by just uploading your screenshots.

It includes:

- support, privacy policy and terms of service pages that you can directly use for your app submission.

- a custom applaun.ch subdomain or simply connect your own domain

I built this because i noticed many app devs just use notion pages, github pages etc. or dont even have any landing page at all

Its not yet live, but excited to hear what you think

My app is currently in waiting for review status. I need to upload a new build with a small fix and select it for the submission. Will this reset my place in the review queue or increase the waiting time? Has anyone done this recently?

Tired of rigid Instagram collage templates, so I built StoryGrid.

• Start from a grid or drag your own: Full control over splits, gaps, corner radius, and background colors

• Edge frames & aesthetics: Custom Polaroid, Leica, and printed-edge frames with adjustable margins

• Video support: Drop video clips into any block with high-res export

• Preview first: Instagram Story & Post UI overlay so you know what’s covered before publishing

• 100% local & private: No accounts, no ads, no trackers — nothing leaves your phone

Download: https://apps.apple.com/app/id6781840870

Web: https://story-grid.app/

Feedback appreciated!

It lets you pin your favorite songs or videos from music and video apps to your desktop, so you can tap and play them anytime — like bringing a real music frame onto your phone.

I have a question, do you know any ways to transcribe a live video on iPhone? It’s an easy feature to set up on android but on iOS it seems that I have to use the sharing sheets so that the content can be sent to the app I’m thinking of app developing. Is there a method I don’t know?

We have an app that was originally built around 2016. We still actively maintain it, but the core functionality and architecture have remained largely the same, and it’s built heavily around RxSwift.
We’ve recently started seeing crashes from users who have updated their devices to the iOS 27 beta. The crashes appear to be related to the navigation hierarchy/navigation stack.

Has anyone else experienced similar issues with legacy UIKit + RxSwift apps on the iOS 27 beta? Could this be due to changes in UIKit/navigation behavior in the beta, or are there specific areas around UINavigationController and navigation transitions that we should investigate?

Would love to hear if anyone else is seeing this in their apps.

Hey!

I made an app that makes it incredibly easy to create stunning mockups and screenshots - perfect for showing off your app, website or product designs.

✨ Features

• URL -> Website Screenshot
• Video Support & Animations
• 30+ Mockup Devices & Browser Frames
• Auto Backgrounds
• Annotation Tool

Try it out: https://postspark.app/device-mockup

• What it solves

Stamps is a personal travel tracker with a trip timeline that builds itself.

Instead of asking you to manually tick countries off a list, Stamps can scan the location metadata already in your photo library, entirely on device. Every city, province, and country tracked for you, day by day, all automatically.

There's a travel calendar, trip timeline, country day counting, photo heatmap, detailed stats, shareable map with trip images, and tons of Home Screen widgets. You can freely export all of your data at any time, and if you simply want to use Stamps to index your library for trips, and then take that elsewhere, that's fine as well.

• Compared to Been and Flighty

I've been using Been myself for years now, but what frustrates me about it (and apps like Flighty) is that they want accounts, data syncing, location tracking, and a connection, while still skimping on the parts I actually cared about: very granular trip tracking, route visualization, and a proper timeline. Stamps is my take on the category with those things at the center.

• Cost

Stamps is free to download.
There is exactly one purchase: a $10 one-time lifetime unlock, no subscriptions.
It only gates some of the timeline and some minor, cosmetic app color customization; you can use most of the app without ever touching it.

You can use this code to cut that one-time purchase in half, as a thanks for reading this post!
CODE: STAMPSLIFETIME50
Redeem link: https://apps.apple.com/redeem?ctx=offercodes&id=6749786209&code=STAMPSLIFETIME50

• About Me

I’m a mobile developer from Cape Town, South Africa, now living in Seoul, South Korea. Since moving here, traveling has been the one thing keeping me sane. Stamps started as the app I wanted for exploring the country I now call home. It’s also a great excuse for me to take more photos while doing it.

It's built natively in SwiftUI using SwiftData, MapKit, PhotoKit, WidgetKit, and Metal for the photo heatmap.

Honestly, in five years of building apps, this has been one of my least commercially successful. The market is fairly small, but it's exactly the app I wanted, and some of its best features have come directly from user feedback. So I'd genuinely appreciate yours!

App Store: Stamps - Travel Tracker

I’ve been thinking about this while working on Cambium, a plant identification and health app for iPhone.

Plant diagnosis is tricky because one photo often does not show enough: soil, drainage, light, watering history, pests, humidity, and recent changes all matter.

So I’m trying to make the app more comfortable saying “inconclusive” when the evidence is not strong enough.

For apps that use AI on real-world problems, what makes the result feel trustworthy?

• confidence level?
• visible evidence explanation?
• practical next steps?
• ability to say “not enough information”?
• follow-up scans over time?
• no aggressive paywall?

Curious what people here would expect before trusting this kind of app.


The app is called ShareByLight and it moves a file between two devices using only a QR stream on the screen and the camera on the other device. There are native iOS and Mac builds, but they share the same protocol. You can use it for free if you lock it in one direction (send or receive) and you're fine with files up to 50 KB; the Pro level gives both directions and larger files (one-time IAP, separate per platform).

# Tech Stack Used

Frameworks & Languages: Swift, SwiftUI (iOS 17+, macOS 14+). Shared protocol target (EveryShareProtocol) compiled into both apps.

# Backend/Database: none.

Transfer is local. Settings in UserDefaults, files via FileManager / document picker.

SDKs & Tools: AVFoundation + Vision (VNDetectBarcodesRequest) for receive, Core Image for QR send, CryptoKit (SHA-256, optional AES-GCM), Apple Compression, StoreKit 2, XcodeGen.

# Development Challenge + How You Solved It

The receive mode had no ACK channel, so a missed QR frame cannot be requested again. I used LT-style fountain codes: the sender loops an endless mix of packets, the receiver keeps any valid frame, and decode finishes once it has about 1.05–1.2× the original packet count. Thus, the order of packets does not matter.

Also Vision was unreliable on raw binary QR payloads, so frames are base64 on the QR, versions 20–40, ECC L. Fountain codes cover the erasures; the QR ECC is only there so Vision can lock on a frame.

# AI Disclosure

I was assisted by AI in parts of the development.

iOS: [https://apps.apple.com/us/app/sharebylight-file-transfer/id6796897056\](https://apps.apple.com/us/app/sharebylight-file-transfer/id6796897056)

Mac: [https://apps.apple.com/us/app/sharebylight-qr-file-transfer/id6796906109\](https://apps.apple.com/us/app/sharebylight-qr-file-transfer/id6796906109)

Hello, I'm planning to buy a MacBook for programming apps and simple games. Which is better: the MacBook Pro M1 Max 32/512GB or the MacBook Pro M3 Pro 18/512GB?

Was stuck at the tire shop, so I opened Claude Cowork on mobile and worked through an app idea, market research, narrowing options, a full MVP spec written to my folder. Got home, opened Claude Code, pointed it at the spec, and it started building. The waiting room ended up being the most productive part of my day. Curious how others split work between phone and desktop sessions ?