Recently, I deployed an app on the App Store and it got rejected because we weren’t using Apple’s In-App Purchase system.
If your iOS app has digital subscriptions, Apple generally requires IAP, meaning around 30% of the transaction goes to Apple.
That can obviously feel painful for some founders.
One alternative is to have a website where users manage their plans and subscriptions.
The iOS app can then focus on the actual product and the user’s account.
For example, “Upgrade Plan” can take users to your website to manage their subscription.
It’s not the cleanest solution, and Apple’s rules around this can be nuanced.
But it’s an architecture worth considering depending on your app and the applicable App Store rules.
I Go through Formbricks Codebase and find a criticcal issue of their webhook architecture..made an architecture change put an pr also raise an issue got reply from them that they are not currently accepting community contribution so my pr did not merge but what feels special is that they acknowledged my issue and thinks about my proposed architecture .. Sometimes Win is not Merging pr communication and acknowledgement also matter..
Issue link:- https://t.co/vSZRIOx0j1
I Go through Formbricks Codebase and find a criticcal issue of their webhook architecture..made an architecture change put an pr also raise an issue got reply from them that they are not currently accepting community contribution so my pr did not merge but what feels special is that they acknowledged my issue and thinks about my proposed architecture .. Sometimes Win is not Merging pr communication and acknowledgement also matter..
Issue link:- https://t.co/vSZRIOx0j1
We built the app for mobile.
But Apple reviewed it on an iPad — and that’s where we got rejected.
We built the app using Expo, and our target audience was mobile users, so our development and testing were mainly focused on mobile devices.
The problem? We hadn't explicitly disabled tablet support in our app.json, so Apple tested the app on an iPad and found UI overlapping issues.
Initially, I thought we would need to spend weeks making the entire app properly responsive for iPad.
Then I found a much simpler solution: supportsTablet: false.
After adding it to app.json, the app opened on the iPad using the mobile layout instead of trying to behave like a tablet app.
The overlapping issues were gone. One configuration change solved what initially looked like a much bigger UI problem.
The lesson: Don't assume that not targeting a device means it won't be tested.
Before rewriting your UI, check your platform configuration first. Sometimes the fix isn't more code — it's one line in app.json.
We built the app for mobile.
But Apple reviewed it on an iPad — and that’s where we got rejected.
We built the app using Expo, and our target audience was mobile users, so our development and testing were mainly focused on mobile devices.
The problem? We hadn't explicitly disabled tablet support in our app.json, so Apple tested the app on an iPad and found UI overlapping issues.
Initially, I thought we would need to spend weeks making the entire app properly responsive for iPad.
Then I found a much simpler solution: supportsTablet: false.
After adding it to app.json, the app opened on the iPad using the mobile layout instead of trying to behave like a tablet app.
The overlapping issues were gone. One configuration change solved what initially looked like a much bigger UI problem.
The lesson: Don't assume that not targeting a device means it won't be tested.
Before rewriting your UI, check your platform configuration first. Sometimes the fix isn't more code — it's one line in app.json.
I recently spent way too much time just trying to manually check our infrastructure status and chase down cost optimizations. It wasn't that the data wasn't there; it was that accessing it meant opening 10 different tabs, running manual checks, and completely breaking my flow state.
The "Autonomous Agent" Trap
Right now, everyone is hyping up "autonomous AI agents" that take action on your cloud for you. Honestly? Giving an AI write-access to production infrastructure terrifies me. I don't want an agent making unchecked architecture changes—I want full control. I just don't want to spend half my day clicking through dashboards.
The Solution: A Custom AWS MCP Server
So I built a middle ground: a custom AWS MCP (Model Context Protocol) server.
Instead of letting an agent run wild, I connected this read-only MCP server directly to Claude Desktop. Now, the AI has real-time context of my entire AWS setup, but I keep my hands firmly on the steering wheel.
Instead of hunting through CloudWatch, EC2, or billing dashboards, I just ask:
• "What's the current status of our infra?" • "What's our cost probability/forecast looking like?" • "How many EC2 instances and NAT gateways do we have active across availability zones?" • "Is there anything running right now that needs optimization?"
It queries the infrastructure, aggregates the telemetry, and gives me a clean, actionable answer in seconds.
The Vision: Voice AI Infrastructure Assistant
The next step is where this gets really interesting: Voice AI integration.
Imagine treating your AWS setup like JARVIS. Walking up to your desk and just saying, "Hey AI, how's our infrastructure looking today? Any cost spikes or bottleneck issues?" and getting a brief spoken summary while your coffee brews.
What's Next?
It’s already saved me tons of manual effort, and I’m starting to think about polishing the UI, building a proper website, locking down security, and turning this into a SaaS platform.
Would you use a conversational or voice-driven interface to manage/monitor your cloud infrastructure?
@jackedAJ So what your pov for this We should invest our early days working with startups and make that succesful with efforts or join mnc and have a chill life sacrificing our own growth!.?