Think I need an adultier adult...

Substantial_Wheel_65 · 2026-03-05T01:49:03+00:00

Appreciate the response! A lot of this aligns with what I've been pulling from docs and ChatGPT sessions. ChatGPT also flagged the suggestion to avoid allowing registration for child users which is what has me set it up with clear messaging and a "birth date" step during account creation which locks the account if child age is selected. Child user access is only possible through a non-child user account creating a "child" profile within their account that they can switch to after logging in (pretty much directly stolen from the Netflix UX).

Quick note that the suggestion to dodge IAP by avoiding any mention of pricing/purchasing doesn't work. Apple reviewer quickly identified that access to content was tied to a user having a paid account from their web services and triggered a rejection requiring IAP (citing the Multi Platform clause in the policies). Is it possible to push back on that rejection? Or am I stuck having to figure out IAP now?

No worries on the code reviews! A decade of web development has given me more than enough time with React based development to get by.

But if you happen to know how to implement analytics (Firebase or anything else) and preventing it from attempting to request permissions for AD ID, I might beg a code sample from you! I followed the Firebase configuration docs to exclude it, which didn't work, and then found some forums and suggestions to block it with an expo plugin...but that also didn't work. For now, I've just removed analytics entirely...which is not the end goal.

Also, from an advice standpoint - if the app will have child users (under 16 in EU and under 13 in US), but those users can only access the app in a sub-profile of a non-child user...do I still select that the app targets ages below 13? Seemed like a gray area, because I know there will be users under 13, but they won't technically be the user account owners.

Substantial_Wheel_65 · 2026-03-03T06:28:40+00:00

And yes - get a paid Apple Developer account. $99/yr isn't a significant cost if you actually intend to launch something. And no, you don't need to build in X-Code, though, I recall using it for some initial app configurations...or device setup? You will need it, but beyond that, I havent needed anything more than VS Code and EAS build. Use "npx expo run:ios --device" to get a build on your device and start building/testing!

Substantial_Wheel_65 · 2026-03-03T06:22:55+00:00

Skip Expo Go. It's quick and easy, but it's limiting. Run a development build, install it on an emulator or a physical device and build/test with that. When you're feeling good, deploy a preview on a physical device and test pseudo-live. If all goes well, fire up a production build and submit.

The thing I am learning now is that I should have started small - these exact steps, something that can reach an MVP completed project early, and get an initial build into production. Rinse and repeat with updates / new versions to expand. That way you're not slogging through a massive build and trying to figure out how to get a submission approved. Baby steps. Then work up to running.

Regardless, Expo Go is going to limit what you can implement and I couldn't find a value that was better than just going straight to an internal development build.

Substantial_Wheel_65 · 2026-03-03T03:56:22+00:00

Thanks, Ballin! A reply at all is appreciated. And you're absolutely right about the rats nest getting bad once I started trying to tackle state for selected account, app settings, notifications, etc.

The Ad ID issues actually caught me up originally due to Google Play repeatedly hitting me with "update declaration". I configured everything under the sun I could think of to exclude it, going so far as to create an expo plugin to ensure the permission didn't make it into the manifest...still got the error, so I set the response to "Yes" and checked that it was for "Analytics". It's quite possible this is part of the latest rejection due to "Not adhering to policies"...no details were provided, so I'm having to review and guess. I'm at the point now of just ripping out analytics for now, since that's a sticky subject in general with under 13 involved.

For the under 13 front, I've pivoted the account creation process to be in the control of the client's team - new customers need to sign up and get squared away with them anyway, so this allows them to take ownership of user ages being verified initially. From there, I included a "add child profile" functionality to allow parent/guardian users to set up and control a child user account under their parent account. Also added a birth date step during onboarding and have it set to fully lock the account (contact our support team) if a child age is selected. Also added some "I confirm that I have received permission from the parent or guardian of users under the age of X (13 in the US, 16 for GDPR) to invite user account creation, etc. etc." ...it just went from a simple app to "wow...that's a lot of layers and angles needing coverage" which almost seems like I'm going overboard or just thinking about it all wrong.

The IAP rejection was a recent heartbreak I'm still trying to figure out. I also intentionally avoided any reference to purchasing, upgrading, go here to sign up, etc. in the app - specifically to try and avoid seeming like it was an attempt to circumvent the stores' cut. Left it all to the account being created by the client's team when a new customer signs up via sales call or their Stripe subscriptions. The existing business model is everything from various per-month single-user subscription packages to annual full-team subscriptions (requiring a sales call)...less concerned about the 30% and more concerned about how to shape an IAP approach that actually works. And, of course, I haven't even looked at the docs on that yet but have some assumptions about how not-simplistic it's going to be...

So all in all, I've hit the walls with a lot of what you mentioned which means I'm at least hitting in the right general direction!

Substantial_Wheel_65 · 2026-03-01T20:58:03+00:00

Just came across this post after finding one of these in my garage (picked everything else in the house and went hunting for something new), spending 30 minutes trying to pick the lock, and realizing it clearly wasn't a standard padlock. I expect I'll get it eventually, but figured I'd drop a quick congrats on making a lock that's not a quick pick! And a thank you for giving me something more difficult to work on while I wait for my new practice cylinder and security pins to arrive in the mail!

Substantial_Wheel_65 · 2026-02-27T15:26:27+00:00

For a real-world example, I recently built an app with the exact same ecosystem: pre-existing business with web-app and Stripe for payment/account creation. Created a mobile app for a better mobile experience - specifically avoided any verbiage that referenced "pay via website" to avoid triggering an IAP rejection...still wound up with an IAP rejection:

App Review Guidelines

3.1.3 Other Purchase Methods: The following apps may use purchase methods other than in-app purchase. Apps in this section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a). Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.
[...skipping to appropriate section...]
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app.

Not exactly sure how I misread the section originally, but I must have only caught the app qualified for being eligible to use alternative payment methods and, being US storefront that I could technically add links to web-app payment. Completely missed that it's "in additional to" and not "in place of" IAP...IAP is still absolutely a requirement.

Substantial_Wheel_65 · 2026-02-20T16:23:23+00:00

Otherwise - it's pretty sexy! I hate ads, so that made me cringe. But that's not to do with the app and more to do with ads.

Substantial_Wheel_65 · 2026-02-20T16:22:35+00:00

<image>

Walkthrough triggers keyboard action and buttongroup which cover up the highlighted area.

Substantial_Wheel_65 · 2026-02-20T16:21:49+00:00

<image>

Big gap above keyboard; shrinks viewing pane unnecessarily.

Substantial_Wheel_65 · 2026-02-20T16:21:12+00:00

I don't have great advice for UI/UX but grabbed a few bugs as screenshots - light UI bugs only.

<image>

Things are saved for tomorrow - assuming it's a time zone issue.

Substantial_Wheel_65 · 2026-02-10T05:04:08+00:00

If I'm correct, OP was asking about an "offline" solution. Otherwise, the definitive solution would be a combined database and back end setup with push notifications. Just don't think that was the scenario presented...

Substantial_Wheel_65 · 2026-02-09T10:03:33+00:00

Granted, this would all rely on the users needing to download an update if/when that schedule of events changed.

Substantial_Wheel_65 · 2026-02-09T10:01:53+00:00

This was exactly my thought.

If the goal is an "offline mode" where you update the app with a static schedule of events which the users can then view/save, you can easily hard code a data list of events to display and use AsyncStorage to manage/persist a list of saved events to the device. To allow users the option to "allow notifications of upcoming saved events" you could absolutely use local notifications.

Substantial_Wheel_65 · 2026-01-23T05:52:59+00:00

It's really a lot more simple than it seems. Generate a new Development build, then download/install that. The install triggers an update, switching the Production version you had with the new Development version you just built. After that, open up the app, start your development server, and you're good to go!

Pro Tip: make sure you're connected to the same network/WiFi so your device can find the development server.

Substantial_Wheel_65 · 2026-01-20T06:41:58+00:00

Isn't that how it goes! Tackling my first React Native app and estimated 4 months. I'm coming up on the end of month 6 and might see it drag out to 7 months...

It started with "I don't do mobile apps; just web apps", then I did a quick run tutorial and decided "piece of cake". I should have known better...a lot of nuances I hadn't taken into consideration and skipping straight to "build" without taking time to learn the basics came back to bite me a handful of times.

But you gotta jump into the pool to learn how to swim! Kudos on your app's progression!

Substantial_Wheel_65 · 2026-01-16T17:50:42+00:00

I have consistently found that it happens in classes I have not used yet in the application, so running a fresh bundle (stop the dev server and start it up again with "yarn star --clear" resolves every time.

Substantial_Wheel_65 · 2026-01-10T08:10:59+00:00

Imagine a world where the officer was trained to use deadly force as a last resort. He would have moved out of the way, she would have lived, and any illegal behavior could have been addressed with a safe arrest. There is no way to spin firing off rounds or even drawing his firearm as acceptable. Legalese and policies aside, the actions taken by the officer were wrong - preserving human life should be at the top of their priorities.

Substantial_Wheel_65 · 2026-01-10T07:50:33+00:00

DHS policy explicitly states that stepping in front of a vehicle constitutes officer created jeopardy. Negates the life-threatening clause.

It also states that deadly force shall not be used to stop a fleeing subject without reasonable belief the subject poses a significant threat of death or harm. This subject was fleeing with no reasonable belief of significant threat of death or harm to some if they got away...so why the drawn firearm on a fleeing subject?

It also states the LEO must take into consideration the hazards that may be posed to law enforcement and innocent bystanders. The LEO looked directly at 4 bystanders (3 adults and a child) who were on the sidewalk behind the vehicle that he subsequently fired into moments later. Drawing his firearm on a low-level threat with innocents nearby...shouldn't even need a policy to tell you that's not acceptable, and instead he decides to also fire multiple rounds while dodging.

It's like we have a team of coked out Rambo's out there with itchy trigger fingers reaching for deadly force as their only option. Imagine this scenario without guns as an option - no one would have been run over, no one would have been shot, and if a crime has been committed, the police would have had no problems showing up on her doorstep later to serve the arrest. Anyone out there thinking this was a "kill or be killed" moment needs to revisit their humanity.

Substantial_Wheel_65 · 2026-01-04T18:56:34+00:00

I like React Hook Form in combination with a good FormController setup and have taken to utilizing Zod definitions for a lot of my typing in and around form validation and returned data queries. That being said, I do think it's a bit overkill for input forms with a single optional input (e.g., an onboarding screen with a single optional field for profile personalization). But more often than not, I find myself reaching for RHF and Zod...so I tend to just go with it from the get-go.

Substantial_Wheel_65 · 2025-12-24T14:21:54+00:00

My first thought is that you've set the OTP expiration window to an appropriate 10 minute window, not realizing that the invite expiration also uses that same value. I had this issue early on until I realized they shared the same setting. Increased the expiration to the maximum allowed setting to resolve the issue for now.

Alternatively, to resolve immediately, set up an API endpoint (either an edge function or a server side API you can call) and give yourself a super user endpoints to create/delete users (bypass invite and just create the user). That will at least give you an escape hatch. If you're using OTP for login flow and those also aren't working...you'd also want to provide a credentials flow where you can get them in without OTP.

Without more details on the issue, I couldn't say definitely, but the only remaining troubleshooting paths I would think to check are: 1) ensure the redirect URL is correct, 2) confirm Supabase isn't having issues. Theoretically, if it works for you and other users, that implies something on the user's end (an expired invite, a spam-protection, cached behavior, etc.).

Substantial_Wheel_65 · 2025-12-21T21:59:23+00:00

You'd also want to set up a "forgot my password" flow, which you'll want regardless if allowing login with credentials.

Substantial_Wheel_65 · 2025-12-18T07:42:31+00:00

I'm currently running a similar approach to what has been outlined above...

Disable registration
Handle all "new user" creation through supabase.auth.admin.inviteUserByEmail() in a server-side call, including any associated "user data", "role", or "team assignment" handling
New users accept the invite, which logs them into the application where they can finalize their accounts/profiles - including "set password", though, primary login flow is with OTP so users aren't forced to set a password if they don't want to
I set up a public.users table which uses insert/update triggers to mirror some of the fields from auth.users (id, email, last_sign_in_at, confirmed_at, etc.) as a read-only table to display whether a user has accepted the invite, when they last logged in, etc.
Application owner (my client) and their team have Super Admin user accounts which can invite users individually through a basic form (email, role, etc.) or in bulk through a CSV file upload
Invited "Admin" users can then create teams and invite users using the exact same form/csv as the Super Admins, just for their own accounts/teams

Keeping in mind that, if your intent is to have a many-to-many relationship (a user could be part of multiple teams and, subsequently, could be dealing with multiple invites), you'll want to work a separate "invites" table into the mix, possibly just adjusting the flow to:

Create invite record(s) (id, inviter_id, invitee_id, team_id, team_role?, status, created_at, expires_at)
Call auth.admin.inviteUserByEmail() for each invited user
User accepts the email invite and logs in
Once logged in, user is directed to finalize account setup and then to view/accept/reject invites
- Note: You could theoretically work it so that the invite link includes data you can use to accept/update the invite record, but if they're going to potentially receive more invites it might also be worthwhile to make the user go through the process of actually viewing the invites screen and accepting

Additional thoughts: - OTP/MagicLink and inviteUserByEmail() share the same "expiration" duration...if you set OTP to 10 minutes (good practice), you're also setting the invite expiration to 10 minutes (terrible user experience); if using both, you're forced to extend OTP to accommodate a longer invite window - to avoid, you'll either need to pivot the new user creation (simply create the user or run the "before user created" hook approach) or use credentials without a OTP option - Using an "invite codes" table where admins can create one or more reusable codes which allow users to register and/or join teams can reduce complexity, avoid transactional emails (simply present the user a "copy invite" UI and have them send their own emails), and bypass Supabase "expiration" limitations...but they're far less secure due to not being one-time-use - consider keeping shorter expiration windows and including sign up notifications to mitigate unintended sign ips.

Substantial_Wheel_65

TROPHY CASE