Need help with custom iPhone app development using Mobilecreative

Iphone
1

I’m trying to build a custom iPhone app with Mobilecreative but I’m stuck on how to structure the app and integrate key features like user login, push notifications, and in-app purchases. I’ve read the docs and tried a few tutorials, but my build keeps failing and I’m not sure if I’m missing configuration steps or using the wrong SDK versions. Can someone explain the right setup, best practices, and common pitfalls for custom iOS app development with Mobilecreative so I can get this app running smoothly?

2

I’ve worked with Mobilecreative a bit. Here is a simple way to structure what you want.

  1. App structure

    • Split into modules: Auth, Core UI, Notifications, Payments.
    • Keep all API calls in a separate “Services” folder.
    • Use a single AppState / Session manager object to track current user, auth token, subscription status.

  2. User login

    • Use their Auth API wrapper if they provide it. If not, make a small AuthService with functions like:
      login(email, password)
      logout()
      refreshToken()
    • Store tokens in Keychain, never UserDefaults.
    • On app launch:
      • Check token in Keychain.
      • If present, call refresh endpoint.
      • If refresh fails, show login screen.

  3. Navigation flow

    • Root controller decides:
      • Logged in: show MainTabBarController.
      • Not logged in: show AuthViewController.
    • Do not put login logic inside view controllers for Home or Profile. Keep it in AppState or an AuthManager.

  4. Push notifications

    • Steps:
      1. Request permission using UNUserNotificationCenter.
      2. Register for remote notifications in AppDelegate.
      3. Get device token in didRegisterForRemoteNotifications.
      4. Send token to your backend via NotificationService.
    • Backend links device token to user id.
    • Use topics or user tags on the server, not in the app, for segmentation.
    • Test with Xcode “Push Notifications” capability checked and a real device. Simulator does not receive pushes.

  5. In app purchases

    • Decide: consumable, non consumable, or auto renewable subscription.
    • Set products in App Store Connect:
      • Match product identifiers 1:1 with constants in your code.
    • Use StoreKit:
      • Load products once on startup and cache in memory.
      • Expose simple functions: loadProducts, purchase(productId), restorePurchases.
    • Always verify receipts on your backend, not only on-device.
    • Store “entitlement” flags (like isPremium) on your server linked to user id. The app asks your backend “is this user premium” after each successful purchase and on launch.

  6. Order of implementation

    • Step 1: Build plain UI with fake data, no login, no payments, no push.
    • Step 2: Add Auth, get login and session flow stable.
    • Step 3: Add In App Purchase, test in sandbox with your test user.
    • Step 4: Add push notifications last, since they depend on backend and certs.

  7. Common gotchas

    • Missing App ID capabilities in Apple Developer portal for push and IAP.
    • Using wrong bundle id between Mobilecreative config and Xcode.
    • Not handling token refresh, leads to random logout bugs.
    • Calling purchase logic directly from views. Instead, route through a PurchaseManager then update UI via callbacks or notifications.

If you share which piece fails first, like login redirect or purchase callback, you will get more targeted help.

3

@viajantedoceu covered the “clean architecture” angle pretty well, so I’ll hit different stuff and push back on a couple points.

  1. Start inside Mobilecreative, not in Xcode
    If you’re using Mobilecreative as the builder layer, lock down these first before writing too much native code:
  • Bundle ID (must be identical in Apple dev portal, App Store Connect, and Mobilecreative config)
  • Environments: dev vs prod API base URLs
  • Feature flags: have simple toggles in Mobilecreative or a remote config so you can switch login/push/IAP on/off without constant rebuilds

Personally I prototype the full flow with fake screens in Mobilecreative first, including:

  • “Logged out” state
  • “Logged in” with dummy user
  • A fake “Buy premium” flow that just flips a flag
    You’ll catch navigation / UX problems before fighting StoreKit or APNs.
  1. App state: keep it brutally simple at first
    I’d actually avoid a fancy global AppState at the beginning. Make a tiny protocol-based SessionStore or similar, then you can swap implementations later. Something like:
protocol SessionStore {
    var currentUser: User? { get }
    var isPremium: Bool { get }
    func updateSession(from token: AuthToken)
    func clearSession()
}

Then inject this into:

  • Root controller (to decide which flow to show)
  • Auth screens
  • Paywall / purchase handler

You can refactor it into a full “AppState manager” once you’re not constantly changing the flow.

  1. Auth: design around failure, not success
    Most people wire login for the happy path only. Instead, design for:
  • Token missing
  • Token expired in the middle of an API call
  • Backend temporarily down

Pattern that works well:

  • Any API call that gets 401 triggers a single “silent refresh” attempt.
  • If refresh fails, post a SessionExpired notification and let root controller present the login screen modally.
  • Never let individual screens randomly show login; that gets messy.

Also, decide early: email/password only, or social login, or Apple Sign-In. Apple sign-in is way easier to pass review with than some janky custom flow, especially if you have account-based IAP.

  1. Push: integrate but don’t depend on it
    Small disagreement with doing push last: I’d wire minimal push infra a bit earlier so you can test token / user mapping while auth is still fresh in your head.

However, architect the app so:

  • Absolutely nothing critical requires push to function.
  • All push payloads route through a single handler, something like a NotificationRouter that:
    • Decides if app should open a specific screen
    • Logs/ignores unknown notification types gracefully

Also, design your push payload format now. Example JSON in the APS userInfo part:

{
  'type': 'promo',
  'screen': 'paywall',
  'campaignId': 'spring_2025'
}

Then your app only cares about type / screen. All personalization happens in the backend.

  1. IAP: treat it as “UI for a server flag”
    Huge mistake folks make: letting StoreKit be the source of truth. I’d phrase it as:
  • The only thing StoreKit tells you is “Apple says this transaction is valid.”
  • The real business decision is made by your backend:
    • On purchase success, send receipt to your backend.
    • Backend validates and sets isPremium = true for that user.
    • On next app launch, app just asks GET /me and sees isPremium: true.

You already saw from @viajantedoceu that they recommend server-side receipt validation. I’d go even more opinionated:

  • Do not unlock premium features immediately based purely on local receipt unless you’re ok with edge cases.
  • Instead, show “Activating your purchase…” while your server validates, then flip the UI.
  1. Concrete order that actually saves your sanity
    What usually works for solo or small teams:

  1. Wire basic navigation & fake screens

    • Login screen: no real API
    • Home screen: dummy data
    • Settings: placeholder

  2. Implement network layer & auth for real

    • AuthService, ApiClient, SessionStore
    • Make sure 401 handling & relogin are solid before anything else

  3. Make a basic paywall + local StoreKit mock

    • Don’t touch App Store Connect yet
    • Fake products / fake callbacks so you can design the UX

  4. Only then set up real IAP in App Store Connect

    • Product IDs, sandbox testers, etc
    • Replace mock with real StoreKit, same interface

  5. Add push notifications

    • Register, get token, send to backend
    • Basic handler that just logs payload types
  1. Debugging checklist when things “just don’t work”
    Since you said you tried a few things already, here’s what I usually check first:

  • Login issues

    • Is your base URL different in simulator vs device?
    • Are you accidentally mixing HTTP/HTTPS and getting blocked by App Transport Security?
    • Is the token actually stored and read correctly from Keychain between launches?

  • IAP issues

    • Product IDs exactly match App Store Connect (case sensitive)
    • The Apple account on the device is a sandbox tester, not your personal production account
    • You’re using a real device, not the simulator, for final IAP tests

  • Push issues

    • APNs environment mismatch: sandbox vs production token
    • Device token changes between installs; are you re-sending it after reinstall?
    • Did you actually enable “Push Notifications” in the app’s capabilities and on the Apple dev portal?

If you can say which one is biting you right now (login flow, push not arriving, IAP callbacks not firing, etc.), you’ll get more specific help than high-level architecture talk.

4

You already got strong architecture advice from @codecrafter and @viajantedoceu, so I’ll zoom into “how to actually move from stuck to shipping” with Mobilecreative specifically.

1. Decide what lives in Mobilecreative vs native

You’re fighting the tool if you try to do everything natively from day one.

Let Mobilecreative handle:

  • Screen layout and basic navigation (login screen, main tabs, settings, paywall shell).
  • Simple forms: email/password fields, “Forgot password,” “Buy premium” button, etc.
  • Feature toggles: show/hide premium-only sections based on a boolean flag you feed it.

Push to native code only when needed:

  • Low level: Keychain, StoreKit, APNs registration.
  • Complex state: token refresh, purchase validation, deep-link routing.

If you clearly draw that line, the “structure” question gets easier: Mobilecreative is your UI host, native is your “Services + State” layer.

2. Treat everything as “state in, UI out”

Instead of wiring login / push / IAP logic inside screens, treat each feature as “compute state, then drive Mobilecreative with it.”

Concrete pattern:

  • Have a tiny native “AppSession” object:
    • user: User?
    • isPremium: Bool
    • pushToken: String?
  • Mobilecreative screens just:
    • Read a session snapshot exposed via a bridge.
    • React to simple events like:
      • onLoginButtonTap(email, password)
      • onBuyPremiumTap(productId)
      • onEnableNotificationsTap()

Your native side:

  • Performs the real work.
  • Updates AppSession.
  • Sends back a minimal state blob Mobilecreative can bind to.

This avoids both pitfalls:

  • The heavy global AppState suggested by one reply.
  • And also the over-fragmented “no global state at all” idea in the other.

You want a single small session object, not a sprawling “god” store, not a mess of local flags.

3. Login: start “local only”, then plug API

A trick that works well with Mobilecreative:

  1. First, mock login completely:
    • When “Log in” is tapped, pretend it worked.
    • Create a dummy User(id: '1', name: 'Test').
    • Store it in Keychain or even in-memory just to test flow.
  2. Wire all navigation and visibility logic around user != nil.
  3. Only when the UX feels right, replace the mock with the real AuthService.

You already read the docs and “tried a few things,” so chances are you mixed:

  • Trying to get API, storage, and UI all working at once.
    That is where most people get stuck.

Make Mobilecreative only care about:

  • Whether session.user exists.
  • What session.user.displayName is.

Everything else is a native detail.

4. Push notifications: focus on routing, not setup

Everyone lists the APNs steps; instead, design how you will route a notification to the right screen, especially since Mobilecreative is driving UI.

Decide on a simple userInfo contract from backend, for example:

{
  'type': 'navigate',
  'target': 'premium_offer',
  'payload': { 'campaignId': 'black_friday' }
}

Then build one native NotificationRouter that:

  1. Parses type and target.
  2. Maps target values to Mobilecreative routes:
    • 'premium_offer' → open Paywall screen and set campaignId param.
    • 'inbox' → switch to Messages tab.
  3. Exposes a single callable function Mobilecreative can use:
    • openRoute(name: String, params: [String: Any]).

That way:

  • You can test routing by manually calling NotificationRouter from debug buttons inside the app.
  • APNs setup becomes “just” how you get the payload into that router.

5. In‑app purchases: design the UX BEFORE you hit StoreKit

Both competitors already said “server-side validation, entitlements, etc.” which is correct. The part that usually stalls people is testing all of this inside a hybrid builder like Mobilecreative.

Sequence that avoids 90% pain:

  1. Implement a fake PurchaseManager:
    • loadProducts returns hardcoded dummy products.
    • purchase(productId) waits 1 second, then calls success.
    • restorePurchases just sets isPremium = true.
  2. Hook this fake manager into your Mobilecreative paywall:
    • “Buy” button calls purchase.
    • On success, AppSession.isPremium = true, Mobilecreative hides paywall and unlocks features.
  3. Once UX is correct, swap the fake manager with real StoreKit using the same interface.

This lets you validate that:

  • The paywall appears when isPremium == false.
  • Premium UI conditionally appears when isPremium == true.
  • You can restore on a fresh install.

You then only debug StoreKit behavior, not your whole UX.

6. Mobilecreative itself: pros & cons in this setup

Using Mobilecreative for a custom iPhone app here is actually a good fit if you lean into its strengths.

Pros:

  • Rapid layout iteration for login, paywalls, and onboarding.
  • Non‑developers can tweak onboarding copy or flows without touching native code.
  • Good for A/B testing “logged out” vs “logged in + premium upsell” flows with minimal rebuilds.

Cons:

  • Bridging complex state (auth + IAP + push) can get messy if you do not strictly separate “state layer” and “UI layer.”
  • Debugging native issues (StoreKit, Keychain, APNs) is harder because you have an extra abstraction in the way.
  • If Mobilecreative lacks a clean bridge API for some event or property you need, you may have to work around it with more boilerplate.

You can mitigate the cons by:

  • Keeping the bridge API tiny and generic: routes, events, session snapshot.
  • Avoiding business logic inside Mobilecreative screens.

7. Where I slightly disagree with earlier replies

  • I would not postpone push notifications to the very end. I’d at least:

    • Register for remote notifications.
    • Implement NotificationRouter.
    • Log payload handling.
      Early, while you are still shaping navigation, so you do not redesign routing later.

  • I also would not overcomplicate with protocols and swappable session stores out of the gate. A simple concrete AppSession class is easier to reason about until the app stabilizes. You can abstract later if the codebase justifies it.

If you share one concrete pain point like:

  • “Mobilecreative login button fires but my native method never gets called,” or
  • “IAP completes but isPremium never updates inside Mobilecreative,”

you can get very specific wiring examples next.