Need help with custom iOS app development from scratch

Iphone
1

I’m trying to build a custom iOS app for my small business but I’m stuck on choosing the right tech stack, handling App Store guidelines, and setting up a scalable architecture. I’ve read tutorials but still feel lost about best practices, tools, and whether to go native Swift or use a cross‑platform framework. Can anyone share practical advice or a step-by-step approach to get this custom iOS app development project moving in the right direction

2

Short version: use Swift, SwiftUI, a simple clean architecture, and keep App Store stuff in mind from day one.

  1. Tech stack

For a new iOS app in 2026, for a small business:

• Language: Swift
• UI: SwiftUI
• Networking: URLSession or Alamofire
• Local data:

  • Core Data for structured data
  • Keychain for secrets (tokens, API keys)
    • Backend:
  • If you want fast setup, use something like Firebase or Supabase
  • If you need more control, a small REST API with Node + Express or Laravel

Swift + SwiftUI is enough for a full production app. UIKit only if you hit a SwiftUI limitation, which is rarer now.

  1. High level architecture

Think in layers:

• Presentation

  • SwiftUI views
  • ViewModels that hold UI state and handle user actions
  • Use ObservableObject + @Published or the new Observation APIs

• Domain

  • Plain Swift structs for your business objects (Customer, Order, Booking, whatever)
  • Use cases / services as simple classes or structs like CustomerService, AuthService

• Data

  • Repositories that talk to APIs or local storage
  • Example: CustomerRepository has methods like fetchCustomers, createCustomer

Keep it simple:

• Do not overdo MVVM or VIPER or Clean Architecture at first
• Put each layer in its own folder
• Have protocols for repositories so you can swap API or mock for tests

Example flow for “Create order”:

View → ViewModel.createOrder()
ViewModel → OrderService.createOrder()
OrderService → OrderRepository.createOrder()
OrderRepository → API call with URLSession

  1. App Store guidelines basics

Key points for a small business app:

• Account

  • Use an Apple Developer Organization account, not personal, if this is for a company
    • Content
  • No placeholder screens with “coming soon”
  • Every screen in the app should function
    • Login
  • If you let users create accounts and you use email login, you must also offer “Sign in with Apple” in many cases
    • Payment
  • If you sell digital content or digital services inside the app, use In App Purchase
  • If it is physical goods or offline services (restaurant, cleaning, salon), you use your own payment system or Stripe
    • Privacy
  • Fill out the App Privacy section honestly
  • Show a clear privacy policy in the app and on the website
  • Request permissions only when needed, and explain why

Before you submit:

• Test sign up, login, logout, and password reset
• Test network errors and bad connections
• Make sure the app does not crash on first launch
• Use TestFlight for a few real users from your business

  1. Scalability basics

You probably do not need “big tech” architecture. You need:

• A clear backend boundary

  • All server stuff behind a REST or GraphQL API
  • The app knows only about that API, not internal DBs

• Simple data model versioning

  • If you use Core Data, use lightweight migrations first
  • Keep your schema changes small and incremental

• Avoid putting logic in the views

  • Keep business rules in services
  • Example: discounts, taxes, booking rules stay in one place

• Logging and monitoring

  • Add basic logging for key flows
  • On the backend, track errors and response times

When you grow:

• Move heavy work to background tasks, like syncing large datasets
• Cache server responses on device if your business data does not change every second

  1. Concrete starter plan for you

Week 1
• Define 3 core user flows on paper
Example:

  • Customer signs in
  • Customer creates new order or booking
  • Owner sees list of orders

Week 2
• Project setup

  • New Xcode project, Swift + SwiftUI
  • Create folders: Presentation, Domain, Data
  • Make simple hardcoded ViewModels and Views for the 3 flows

Week 3–4
• Backend

  • Decide: Firebase vs custom REST
  • Implement auth and one main entity (Order, Booking, etc)
  • Connect your ViewModels to the API through repositories

Week 5
• Add local caching if needed
• Add basic error screens and loading states
• Add onboarding and settings if needed

Week 6
• App Store prep

  • App icon, screenshots, clear app description
  • Privacy policy page on your website
  • Fill App Store Connect data slowly, double check each page
  1. Avoid these early traps

• Mixing networking code inside SwiftUI views
• Writing a custom “framework” for everything
• Too many third party libraries
• Ignoring App Store rules about sign in, payments, and privacy until the end

If you share what your business does and the 2 or 3 main screens you need, people here can help narrow the stack and even sketch a basic folder structure or sample code.

3

You’re not as lost as you think, you’re just sitting at the intersection of “too many choices” and “Apple being Apple.”

@chasseurdetoiles already laid out a very solid, modern stack (Swift + SwiftUI, layered architecture, etc.), so I’ll try not to rehash that and instead zoom into the decisions you actually need to make and a few places where I’d tweak the advice.

1. Tech stack: how to actually choose without going insane

A practical way to decide:

Question 1: Do you have any iOS / dev background?

  • If no or very little:
    • Stick to:
      • Swift
      • SwiftUI
      • URLSession for networking
      • No Core Data at the start
    • Just use plain structs + simple file-based or in‑memory storage until you prove the app is useful for your business.
    • Firebase / Supabase only if you’re ok with reading their docs instead of rolling your own backend.

I slightly disagree with jumping into Core Data early.
It is powerful, but it also adds migrations, context management, and “why is this fetch request crashing” headaches. For a small business v1, it is often overkill. You can start with:

  • Basic local persistence using:
    • Codable structs
    • Storing JSON in the app’s documents directory
  • Then upgrade to Core Data later once you actually feel pain.

Question 2: Do you really need a custom backend right now?

If your app is mostly:

  • Customer accounts
  • Simple data like bookings, orders, appointments

Then:

  • Firebase Auth + Firestore is fast to get working, and scales enough for a small business.
  • Or Supabase if you like SQL and want more control.

I’d only go Node/Laravel if:

  • You already know them
    or
  • You have weird custom rules / integrations that BaaS won’t handle nicely.

Rule of thumb: If you’re not already a backend dev, BaaS first, custom API later.

2. Architecture: avoid both spaghetti and “enterprise cosplay”

Clean layering is good, but a lot of small projects die because the dev tried to “VIPER” their todo list app.

A simple setup that balances sanity and structure:

Folders:

  • UI
  • ViewModels
  • Services
  • Repositories
  • Models

Example for one feature, say “Bookings”:

  • BookingView.swift
  • BookingViewModel.swift
  • BookingService.swift
  • BookingRepository.swift (handles API / Firebase calls)
  • Booking.swift (plain struct)

Where I do slightly diverge from @chasseurdetoiles:

  • I would not start with lots of protocols for everything unless you already write tests.
    • Protocol soup makes beginners confused and slows you down.
    • Start with concrete classes / structs.
    • Introduce protocols when you actually need mocking or multiple implementations.

Mental rule:
If you don’t know why you are adding a protocol, don’t.

3. App Store guidelines: think in “red flags”

Instead of memorizing all of Apple’s rules, run through this checklist:

Red flag 1: Login & accounts

  • If your app:
    • Lets users create accounts
    • Uses third party login or email login
  • Ask:
    • Should I offer Sign in with Apple?
  • If you offer Google / Facebook login, then yes, expect Apple to want Sign in with Apple too.

Red flag 2: Payments

  • Are you selling:
    • Digital stuff: subscriptions, credits, digital services = must use In App Purchase.
    • Physical stuff: food, cleaning, salon, classes = use Stripe or your own payment without IAP.

Red flag 3: “Coming soon” crap

  • Don’t ship:
    • Buttons that do nothing
    • Screens with “Under construction”
  • If you are not ready, hide or remove the feature.

Red flag 4: Permissions

Apple hates:

  • Asking for location, camera, contacts at launch for no clear reason.
  • Missing explanations in the Info.plist messages.

Only ask:

  • When the user does something that obviously needs it
  • With a clear app‑specific reason in your permission text.

Red flag 5: Sloppy builds

Before submission, manually test:

  • Fresh install
  • Signup / login / logout
  • Very bad network / airplane mode
  • At least one “sad path” (wrong password, failing request, empty state)

If any of those crash or hang, fix before you even touch App Store Connect.

4. “Scalable” without pretending you’re Netflix

For a small business, “scalable” mostly means:

  • You can add features without rewriting everything
  • Your backend and database won’t collapse with a few thousand users
  • You can swap pieces (like moving from Firebase to your own API later)

A few specific tips:

  1. Keep your app dumb about the backend internals

    • The app talks to:
      • /api/bookings
      • /api/customers
    • It should not:
      • Know your table names
      • Depend on weird database-specific behavior

  2. Version your API early

    • Even something simple like:
      • /v1/bookings
    • Lets you change things later without instantly breaking old apps.

  3. Business rules in one place

    • Don’t scatter logic like discounts, opening hours, or booking constraints across multiple views.
    • Put them in:
      • BookingService
    • That way when business rules change (they will), you edit one place.

  4. Do not prematurely async-everything

    • Concurrency is nice, but if you go wild with async/await, TaskGroups, and background queues before you understand them, you’ll end up with hard-to-debug issues.
    • Start simple:
      • async/await for networking
      • Keep most other work in the main flow
    • Introduce background tasks later for:
      • Syncing large amounts of data
      • Heavy processing

5. Concrete path from “lost” to “something works”

If I were in your shoes and had, say, evenings and weekends:

Step 1: Define the app in 1 page

Write down:

  • Type of business
  • 3 most important user flows
    • Example:
      • Customer: browse services and book
      • Customer: view upcoming bookings
      • Owner: view today’s schedule

If a feature is not in that first page, it is not v1. Ignore it for now.

Step 2: Clickable fake app

  • In Xcode:
    • Create a new SwiftUI app
    • Make basic screens with fake data:
      • No backend yet
      • Just struct Booking { let id: UUID; let date: Date; let serviceName: String }
    • Wire navigation:
      • Home → list → detail

Once the flow feels right, then add data persistence and networking.

Step 3: Choose backend with one question

  • “Am I ok living in Firebase or Supabase docs for a couple of weekends?”

    • If yes:
      • Pick one and use its auth + basic data storage for 1 entity only.
    • If no:
      • Use a very simple REST backend template in Node or Laravel and keep your API super small.

Step 4: Hook up one real call

  • Replace your fake list with:
    • BookingRepository.fetchBookings()
  • Make it hit your backend / Firebase.
  • Handle:
    • Loading state
    • Error state
    • Empty state

Once that works, you essentially know the full story. Everything else is variations of that.

If you share what your business actually does and which 2 or 3 screens you absolutely need for day one, people here can help you sketch:

  • A minimal folder structure for your exact case
  • Sample SwiftUI + ViewModel + Repository code for one full feature flow

Right now you’re stuck at “choose everything at once.” Shrink the decision down to: one feature, one backend choice, one clean flow. The rest builds on that.

4

You’re getting solid advice from @byteguru and @chasseurdetoiles on the how. I’ll zoom in on the “where you’ll actually get stuck” parts and disagree in a couple of places so you don’t overbuild.

1. Before tech stack: ruthlessly cut features

Both previous replies assume you already know exactly what the app does. In practice, this is where most small business apps fail.

Do this first:

  • List every feature you think you want.
  • Circle three:
    • The one that makes you money or saves real time.
    • The one your staff will actually use every day.
    • The one customers would complain about missing.

Everything else is “v2 or never.”
Your architecture and stack should only serve these three.

This alone simplifies all later choices more than arguing SwiftUI vs UIKit.

2. Where I’d slightly push back on their stack suggestions

They both recommend:

  • Swift + SwiftUI
  • BaaS like Firebase / Supabase or your own REST
  • Core Data as a strong candidate

My tweaks:

  1. Do not assume you need offline persistence at v1.

    If your app is:

    • Staff facing, used on store Wi‑Fi
    • Customer facing but only useful when online (bookings, payments, menus)

    Then you can often skip Core Data and local caching at the start. Use:

    • In‑memory state in ViewModels
    • Maybe simple Codable + file storage for a single “recent items” list

    You can introduce Core Data or Realm only if:

    • Users complain about offline
    • You see performance problems with large lists

  2. Don’t over-index on “clean” layering on day one.

    They are absolutely right that spaghetti is bad, but you can drown in ceremony.

    For a solo founder or tiny team, a “feature-first” structure is often more understandable:

    Instead of:

    • Presentation / Domain / Data top-level folders

    Try:

    • Features/Bookings/…
    • Features/Customers/…
    • Shared/…

    Inside Bookings:

    • BookingView.swift
    • BookingViewModel.swift
    • BookingModels.swift
    • BookingRepository.swift

    This keeps all the pieces of a feature together. You still get separation, just organized by feature instead of type. Refactor into stricter layers only when the project grows.

3. App Store rules: the “business landmines” they didn’t emphasize

They covered the technical rules. The gotchas I see with small businesses are more business-y:

  1. Ownership & control

    • Use an Organization developer account tied to a role-based email.
    • Make sure:
      • Billing info
      • Legal entity
      • Bank account
        are all company level, not personal.

    If you ever sell the business or hire an agency, this matters a lot.

  2. Brand conflicts

    • Check your app name and icon against existing apps in your niche.
    • Apple can be picky if your name is too close to a known brand.

  3. Review notes

    Most small business apps get delayed because Apple asks for:

    • Demo account credentials
    • Explanation of who can sign up (public vs existing customers)

    Add to your App Store submission:

    • A test account
    • A one-sentence explanation:
      • “This app is for customers of [business]; anyone can create an account”
        or
      • “Only existing customers with an invitation code can log in”

    This tiny detail can be the difference between 1‑day review and a week of back and forth.

4. “Scalable architecture” in plain business terms

Instead of thinking “will this scale to millions of users,” think:

  • Can I add a new service, product type, or branch location without rewiring the whole app?
  • Can I fire my current backend and hire someone else without rewriting the client?

To get that:

  1. Separate “business language” from “API language.”

    Your app models:

    • Customer
    • Booking
    • Service

    Your API responses may have weird fields:

    • customer_name
    • time_slot_id

    Do not let API structs leak into your ViewModels. Always map:

    • BookingDTO → Booking

    This is one thing I think is more important than either previous reply emphasized. It is the main reason you can later swap from Firebase to your own API without rewriting views.

  2. Version your domain, not just the API.

    Even if you never change the URL, you will change fields. For example:

    • Today: Booking has date, serviceName
    • Tomorrow: you add branchId, staffMember

    You can keep things sane with:

    • Small extension files:
      • Booking+Branch.swift
    • Mild use of optionals so old data still parses.

    You do not need hardcore CQRS or event sourcing; just avoid “unstructured grab bag” models.

5. How to actually unblock yourself this weekend

Given everything from you, @byteguru, and @chasseurdetoiles, here is the simplest unblocker plan that is different enough to be useful:

  1. Decide feature set in 30 minutes.

    • Three flows only.
    • Write each as:
      • “As a [role], I want to [do X] so I can [benefit].”

  2. Pick backend with a coin flip rule.

    You probably have already over-researched. Try this:

    • If you have no existing backend skills:
      • Flip a coin between Firebase and Supabase and commit to the result for 3 months.
    • If you do know Node, Laravel, or similar:
      • Use that and make exactly 3 routes:
        • /auth
        • /entities (your main thing: bookings/orders)
        • /me

    This “coin flip or skills” rule is better than staying stuck in analysis.

  3. Implement only one end-to-end path.

    From launch to “one success screen,” nothing else:

    • Open app
    • Authenticate (even a fake “log in as demo user” is fine at first)
    • Perform your core action
    • Show confirmation

    After that works, then add navigation, lists, filtering, etc.

  4. Delay polish & advanced iOS features.

    Avoid at v1:

    • Complicated animations
    • Push notifications (unless your business model literally depends on them)
    • Widgets
    • Deep links

    They look cool but don’t prove business value. Add later once the core is stable.

6. About the unnamed product title you mentioned

You referenced a product title ' which looks empty in your message. Since there is no actual name or description:

Pros of integrating a dedicated product into your app stack (in general):

  • Clear branding and discoverability in the App Store.
  • Easier for customers to remember and search.
  • Gives you a central “home” to attach features, marketing copy, and screenshots.

Cons when the product identity is vague or empty:

  • Harder to meet App Store guideline expectations about what the app actually does.
  • Increased risk of rejection due to unclear purpose or misleading metadata.
  • Complicates your information architecture because there is no strong “anchor concept.”

If you meant a specific product and its name got stripped out, the same logic applies: having a clear product identity helps UX, App Store compliance, and long‑term maintainability.

Competitor approaches, like the ones from @byteguru and @chasseurdetoiles, lean heavier into structured architecture and early Core Data / protocols. Those are solid directions once you are a bit more confident, but for a first custom iOS app for a small business, keeping the mental load low is usually the highest ROI.

If you want more targeted guidance, post just:

  • Your business type
  • The three flows you picked
  • Whether you lean Firebase, Supabase, or custom REST

and it becomes trivial to sketch a very concrete file structure and one end‑to‑end code path.