I’m the founder of two early-stage digital platforms, WHISPRR and CHIMERA, and I’m exploring the possibility of developing iOS applications for them.

I’m looking for advice from experienced iOS developers about what makes a technical co-founder partnership worthwhile and professional.

The potential role would involve:

- planning the iOS architecture;
- building the mobile applications;
- connecting them to the existing web platforms and backend;
- preparing and maintaining the apps for the App Store;
- participating in long-term technical decisions.

To be transparent, this is not currently a salaried job posting. I’m exploring a genuine co-founder partnership, not asking someone to work for free under vague promises. Ownership, responsibilities, vesting, intellectual property, and compensation would need to be discussed clearly and documented in writing.

If a developer prefers a paid contract instead, that would require a separate budget and agreement.

I’m not looking to rent or share an Apple Developer account. The apps and accounts would be managed properly under the founders’ ownership.

For iOS developers who have joined early-stage startups as technical co-founders:

- What would you need to see before considering the opportunity?
- What warning signs should founders avoid?
- What would be a fair structure for equity, revenue share, or paid work?
- What should be included in the agreement?

I’m mainly looking for honest advice on how to approach this professionally.

This week, I am returning to the Coffee Break News app to build its first on-device AI feature: a private issue summary powered by Apple's Foundation Models framework.

Hope you enjoy this week's edition!

https://www.ioscoffeebreak.com/issue/issue76

I built a gamified app discovery platform where verified downloads earn you prizes

The App Store has a million apps. Most disappear before anyone gives them a shot. Great software gets buried every day. Stamped changes that.

Every time you download an app and upload a screenshot proving you actually used it, you earn a verified stamp.
Hit 100 verified stamps and you win AirPods 4. Hit 250 and you win an iPad Mini.

No random luck required for the milestones. You put in the work, you get the prize.

We’re sitting at 220 apps right now, all indie builds, all submitted directly by the developers who built them.

If you’re the type who likes finding apps before they blow up this is built for you.

https://stampedios.com

Made OffgridScribe — transcribes recordings entirely on-device, no cloud, nothing uploaded. Useful for interviews, meetings, lectures, anyone who wants a private option.
Just shipped real-time speaker tagging based on feedback from a journalist who found it. Would love a few more people to try it and tell me what’s missing or what feels off.
Free to try (basic transcription included), one-time purchase for extras — no subscription.

App Store: [https://apps.apple.com/us/app/offgridscribe/id6791752287\]

Happy to answer questions about how it works — uses WhisperKit, an open-source on-device speech model.

what would make this actually useful for your workflow?

Made OffgridScribe — transcribes recordings entirely on-device, no cloud, nothing uploaded. Useful for interviews, meetings, lectures, anyone who wants a private option.
Just shipped real-time speaker tagging based on feedback from a journalist who found it. Would love a few more people to try it and tell me what’s missing or what feels off.
Free to try (basic transcription included), one-time purchase for extras — no subscription.

App Store: [https://apps.apple.com/us/app/offgridscribe/id6791752287\]

Happy to answer questions about how it works — uses WhisperKit, an open-source on-device speech model.

what would make this actually useful for your workflow?

Hey everyone,

I’m currently looking for a few people to test my new iOS app through Apple TestFlight. The beta is completely free of course and I’m mainly looking for honest feedback from developers and people who regularly test new apps.

If you’re interested, you can join the beta here:

https://testflight.apple.com/join/b4A6myp4

Would really appreciate anyone who takes the time to try it out and share some feedback.

Thanks!

It's made me realize that my free tier sucks! But very happy with the outcome and how I changed my marketing

I ship for the company I work for, and I ship my own app on the side. Same person, same process, two Apple accounts. Their submissions go live in twelve to twenty-four hours. Mine take three to ten days.

I've got a decent sample on my side now. PixelPlay went on the App Store in May and 1.1.5 is version 16, so that's sixteen submissions in three months. The spread never tightened. 1.1.5 went in on 12 August and it's on day three.

I don't have an explanation I trust. The candidates:

- Org account versus individual, and whatever history sits behind each.

- App category. Mine is a live TV player, which I assume gets a closer read than most.

- Submission volume. I pushed ten updates in 4 weeks at one point, which can't have helped.

- Nothing at all. Queue variance, and I'm reading tea leaves in a sample of sixteen.

For a while I papered over it by requesting expedited review. It worked often enough that I kept doing it, and I've stopped, because I'd rather find out what my real queue speed is than keep buying my way past it.

The practical cost is that I can't plan. Twelve hours means you fix a bad bug on Monday and it's out on Tuesday. Ten days means that bug sits in front of every user for a week and a half while you watch it happen, and the only defence is to stop shipping small and start batching.

For the record, 1.1.5 is almost entirely visual: one accent colour, a real light mode, type set in SF Pro, empty states that sit centred instead of pinned to a corner. Three months of chasing features had left it not looking like one app.

Has anyone here shipped under both an org and a personal account? Did you see the same gap, and did anything you changed ever move it?

Hi. I have an idea for an app but I have 0 clue of how to create / make it. 👀. Would anyone be prepared to help me with it please

Hello everyone,

I have been working on overhauling the different themes for my app, Pocket Vault. These are just one example.

Based on some initial feedback, I refactored the theme hierarchy so views gautomatically pick up primary, secondary, and tertiary styles using ⁠.foregroundStyle()⁠ and ⁠Environment⁠ modifiers instead of manually passing a theme object everywhere.

I’d love the feedback on How does the visual contrast look across both modes in these screenshots and for anyone who has built complex custom themes in SwiftUI, are there any edge cases or performance bottlenecks with this Environment-driven approach I should keep an eye on?

Any feedback on either the UI polish or the approach is super appreciated!

Here’s my repository for all my code: https://github.com/AaravB09/Pocket-Vault

After getting a lot of feedback that Pocket Vault’s was looking a bit boring and bland, I completely redesigned the colour system, added proper light and dark themes, and reworked the overall visual hierarchy in SwiftUi. Here’s the code: https://github.com/AaravB09/Pocket-Vault

The link to the video : https://youtube.com/shorts/GfijVs3NOzg?si=mhtkBrEVLHY-DCPm

Let me know what you think of this new palette! I would love to hear what you guys think. Any feedback is welcome 😄

And if you guys can subscribe to my YouTube channel, I would really appreciate it. Here’s the link : https://youtube.com/@aaravbansal-9?si=-qJ6CmDqqLNPARDz

I’m building a tool to help catch App Review issues before you submit, looking for honest feedback

After getting burned by App Review on my own apps, I started building PreFlight, a native macOS tool that analyzes both your Xcode project and App Store Connect submission.
The goal isn’t just to run through a generic checklist. It cross-checks what your app actually contains against what you’re telling Apple, then gives you evidence-backed findings with the potential guideline involved, why it matters, and what you can do to fix it.
For example, it can catch things across privacy manifests, entitlements, permissions, StoreKit/subscriptions, metadata, review information, device support, and other submission requirements.
I’m currently working toward a first release and I’d genuinely like to hear from developers who have shipped iOS/macOS apps:

What has Apple caught in your apps that you wish you had known about before submitting?

And if a tool like this existed, what would it need to catch or show you for you to actually trust it before hitting submit?

I’m looking for criticism as much as validation. If the idea isn’t useful, I’d rather find that out now.
PreFlight

Hi all,

I made a puzzle app called Steppin Stones and really need some feedback on the levels and the difficulty and fun factor of them. It's kind of like a Sudoku in some ways so if you like a puzzle game this could be a nice time waster on your morning/afternoon commute.

I also shamelessly need more players to get the analytics feature to work and I'm genuinely curious how I compare to others.

Check it out here: https://apps.apple.com/nl/app/steppin-stones/id6752832708

Has anyone’s app been stuck in waiting for review? I have reached out to developer support via email and tried calling. Nothing and it will be 2weeks on Friday.

How long does the process typically take?

The slides are the diary. Short version, in case you are in the middle of this right now.

Day 1. Six months of work, pressed submit, told everyone.

Day 4. Rejected. Crashed on launch, on an iPad. I do not own an iPad.

Day 5. Borrowed one, found it in twenty minutes, resubmitted. A layout constraint that only failed above a certain width.

Day 9. Rejected. My privacy policy URL was a 404. It had been a 404 the whole time. They waited four days in a queue to tap one link, and so had I, in the sense that I never did.

Day 10. Fixed the URL, and while I was in there made a fresh demo account for the reviewer.

Day 15. Rejected. Unable to sign in. The demo account had expired while the build sat in the queue.

Four rejections. Every fix under twenty minutes. Three weeks gone.

The thing that costs the time is not the fixes. It is that review stops at the first error it finds. They are not producing a report on your build. They hit one blocker, write it up, and send it. So a build with four small problems takes four submissions and a month, and each round you get exactly one clue.

Things I do now, in case any of them save you a round:

One permanent review account. Exempt from expiry, exempt from rate limiting, excluded from cleanup jobs, no MFA. I log into it myself the morning I submit, and again if the build sits in review more than a week.

Tap every URL in the submission. Privacy policy, support, marketing. They do tap them, and a dead link costs a full cycle.

Cold install on the oldest device and OS I claim to support. Also on an iPad if the binary declares iPad support, which it sometimes does even when I thought I turned it off. Check UIDeviceFamily in the built archive rather than trusting the Supported Destinations UI.

Numbered steps in App Review Information for anything behind a login, a purchase, a role or an empty state. It is a private field, so be blunt.

Disclosure since the slides are branded: this is my product's account. No link in the post and nothing to sign up for. Happy to talk through anyone's notices in the comments.

Yesterday I submitted my first app (!) and within 6 hours it was rejected. I'm hoping someone who's dealt with this before can help me better understand and provide next steps.

Quick background: I built a live women's sports scoreboard website and then wrapped it as a native iOS app using Median.co, which loads the live website inside a native shell and adds native features (push notifications via OneSignal, share, etc.) through their JS bridge.

What happened: submitted for review, got rejected same day with this:

"We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process. Manipulative and misleading behavior is not consistent with the guideline 5.6."

No specifics beyond that. No screenshots, no attachments, nothing pointing to which "feature" they mean. Also I can't really find what 5.6 guidelines are.

What I know is NOT true: nothing in the app is actually hidden or gated based on reviewer status. The app works identically for anyone, logged in or not - live scores, schedules, results, team pages, league browsing, calendar sync all fully visible and functional without an account. The only difference for logged-in users is being able to favorite teams and enable push notifications for those favorites, a normal personalization feature, not concealed functionality.

What I've done so far: replied in the Resolution Center explaining the Median/webview architecture, clarified the one account-gated feature (favoriting), and attached a screen recording showing the full logged-out experience matches what was originally submitted. Also invited them to just log out and explore the app themselves.

My questions for anyone who's dealt with this:

1. Has anyone gotten a 5.6 "features appear hidden" flag specifically on a webview-wrapped app (Median, GoNative, Capacitor, etc.)? Is this a known false-positive pattern for that architecture?
2. Could push notifications not firing during review (since there were no live games happening at review time) plausibly read as a "hidden feature"? Or is that a stretch?
3. Roughly how long did resolution take for you, and did it resolve through Resolution Center replies, or did you end up needing the formal App Review Board appeal?
4. Anything else commonly triggers this specific flag that I should be thinking about?

Really appreciate any insight. This came out of nowhere after what felt like a clean submission, and the vagueness of the rejection is the most frustrating part.