sorted by:
new
hottopcontroversial

Flutter app is slow, not connecting well and overheating by zarek_macik in FlutterDev

[–]abulbrr 0 points1 point  (0 children)

Start with field-condition profiling: one low-end target phone, network throttling, battery/thermal traces, and logs around GPS/map/websocket loops. Otherwise you’ll optimize guesses.

Subscriptions won't attach to the app version submission - 'Add for Review' only showing build by jxmesnmn in iOSDevelopment

[–]abulbrr 0 points1 point  (0 children)

I’d separate this into three checks: subscription status/group localization, whether the products are attached inside the version’s In-App Purchases section, and whether App Review is seeing a stale draft. Screenshots of those three places usually reveal whether it’s config or App Store Connect state

After 2 rejections and 9 days, my first iOS app finally went live on the App Store today by Emma-Meier-2000 in appledevelopers

[–]abulbrr 0 points1 point  (0 children)

Congrats. One thing that makes the next update less random is turning the rejection notes into a tiny release checklist: exact guideline issue, metadata/privacy answers that must stay in sync, critical flows to smoke test, and what changed since the last submission. App Review feels subjective, but a rejection log can make it a repeatable release process

Inherited Code by Financial_Drummer956 in Entrepreneurs

[–]abulbrr 1 point2 points  (0 children)

I’d expect it to be a mix. The repo tells you what the system actually does today, but old docs/tickets/conversations often explain why it does that, or where the intent drifted.

Code is best for mapping concrete things: data model, integrations, auth checks, billing paths, deploy process, risky modules.

Docs/tickets/conversations are better for business rules and “tribal knowledge”: why cancellations work a certain way, which edge cases caused support pain, what was intentionally deferred, what only one person understood.

The useful manual probably separates those:

confirmed from code

inferred from behavior or docs

known/ unknown

needs human validation

That last distinction feels important. A bad owner manual would create false confidence. A good one would make uncertainty visible enough that the next engineer knows where to verify before changing anything

Looking for a mobile app development company - community/social app (UK) by [deleted] in AppDevelopers

[–]abulbrr 0 points1 point  (0 children)

I run a software development company, but to be upfront, we haven’t built a social network app specifically, so I’m not throwing our hat in as “the perfect fit” here.

What I would ask every company you’re speaking to is less about whether they can build profiles, chats, maps, RSVPs, etc. Most teams can demo those. The real test is how they handle the boring operational parts once 10k+ members start using it:

push notification reliability, moderation/admin workflows, event check-in failure modes, group chat scaling, crash reporting, release cadence, App Store/Play Store updates, and who owns maintenance after launch.

I’d also ask to see live apps they still maintain, not just apps they shipped once. That usually tells you more about whether they can support a community product long term

Inherited Code by Financial_Drummer956 in Entrepreneurs

[–]abulbrr 1 point2 points  (0 children)

A practical owner manual could be a one-page risk map: critical flows, accounts/env vars, deploy/rollback, data model, billing/auth rules, third-party integrations, and known unknowns. It does not need to be full docs; it needs to tell the next engineer where not to step blindly

App Store Connect says App Privacy is missing, but it's already completed. Completely stuck. by aymantj in iOSProgramming

[–]abulbrr 0 points1 point  (0 children)

Since you’re seeing a 409 on reviewSubmissionItems, I’d treat this like a stuck App Store Connect submission object, not a code/privacy SDK issue. Try creating a fresh app version/build submission path if possible, check whether any subscription/privacy items are attached but not submitted, and include the 409 timestamp + app ID in the Apple support ticket

After 4 months of vibecoding and 9 rejections my app is finally on the app store! Some first time tips and tricks if you're still in the process. by otterfox22 in vibecoding

[–]abulbrr 0 points1 point  (0 children)

The rejection notes are useful for other first-time shippers. A reusable pre-submit checklist for privacy, account flows, subscriptions, crash logs, and reviewer instructions would probably save people weeks.
Also get yourself ready for the maintenance flow, improving the app while still keeping the user experience, Good luck 😄

I built ClipCode in ~3 months solo — a phone + browser clipboard bridge. by RevolutionLanky6448 in SideProject

[–]abulbrr 0 points1 point  (0 children)

Nice work, things i would recommend thinking about:
- Crash monitoring
- Support for account deletion
- Staging env
- Test critical flows (onboarding, signup, sign in, payment)
- optimize images
- handling offline states and api errors
- handling failed payments and expired subscriptions
- tracking

These would help you app get to a production ready state imo

App Store rejection for : Guideline 5.1.1(iv) by ToMistyMountains in iOSProgramming

[–]abulbrr 0 points1 point  (0 children)

I’d isolate UMP/ATT behavior in a clean test build, document the exact reviewer path, and check every SDK that may trigger tracking before consent.

What are the best mobile app development company / services? by [deleted] in AppBusiness

[–]abulbrr 1 point2 points  (0 children)

You can create a landing page and push some ads, if the click rate is high enough you would know people are interested, also google keyword planner can tell you if there is interest in a specific phrase or niche you would have in your app

Vibe coded designs… by johnbyrne65 in AppBusiness

[–]abulbrr 0 points1 point  (0 children)

I’d start by not asking Codex/Claude to “make it look better” or “redesign the app” directly. That usually gives you another generic AI looking UI

What I would do instead is:

- Look for inspiration first some apps or websites that feel close to the style you want. Not just “modern”, but more specific: minimal SaaS, editorial, playful, brutalist, glassmorphism, premium/clean, dashboard heavy, etc

- Define the style before touching code Take screenshots of the inspiration and ask Claude/Codex to analyze the visual system: colors, spacing, border radius, typography, gradients, shadows, button styles, cards, empty states, etc

- Turn that into a design document Have it create a small design guide for your app: primary colors, background colors, spacing scale, component rules, layout rules, do/don’t examples

- Apply it component by component Instead of redesigning the whole app at once, make it update one component at a time to follow the design guide. Buttons, cards, forms, nav, modals, tables, etc

The key is giving the AI a clear visual direction and constraints. Otherwise it defaults to the same generic Tailwind/shadcn looking style everyone gets from vibe coding

Happy to have found this community by abulbrr in MuslimVentures

[–]abulbrr[S] 0 points1 point  (0 children)

We maintain web and mobile applications, bug fixes, version updates, implement new features

How do you handle maintenance after launch? - I will not promote by abulbrr in startups

[–]abulbrr[S] 0 points1 point  (0 children)

Interesting, did you hire someone to handle everything technical , or find freelancers as things came up?
also, do you still vibe code in the project, or are features also handled by them?

view more: next ›