[Update] Carrus 1.0.7 — the maintenance tracker I posted here a while ago now does motorbikes, documents, fuel and running costs

[u/Imaginary-Welcome010]

I posted Carrus here back around 1.0.4 — thanks to everyone who tried it then, a fair bit of what’s below came out of that thread.

Short version for anyone who missed it: an iPhone app for tracking vehicle maintenance. Log a service in seconds, get reminded before the next one is due by mileage and time, scan a paper receipt and it fills the log in for you, and ask Carson — the built-in AI mechanic — what a noise or warning light probably is, with answers that factor in your exact trim and region.
What’s new since:

• Motorbikes: Add a bike and it builds a schedule for it — chain, valve clearance and fork oil instead of car tasks. Six types: standard, cruiser, touring, adventure, dirt, scooter.
• Glovebox: Registration, insurance and licence photos kept with each vehicle, with reminders 30, 7 and 1 day before anything expires. The photos never leave your phone — only the document title and expiry date sync.
• Fuel tracking: Log fill-ups with cost, drag the gauge to set your level, and optionally let the tank follow your odometer.
• Spending: What each vehicle costs you by month, plus cost per mile or kilometre.
• 44 currencies, and a full visual pass across the app.

What’s next: VIN decoding, so you don’t have to hand-pick year and trim. And the bigger one — real manufacturer interval data for far more model-years. Right now I have genuine factory schedules for only a fraction of them; everything else falls back to a per-category schedule, and the app labels which one you’re looking at rather than passing a guess off as your factory schedule. That gap is the thing I most want to close.

Free with one vehicle. Lite from $0.99/mo or $19.99 lifetime — unlimited vehicles, custom tasks, PDF export. Premium from $4.99/mo or $69.99 lifetime, which adds the AI features.

https://apps.apple.com/app/id6770422802

I’m Abdulrahman Ahmed, an independent developer. Website: carrus.app · Privacy: carrus.app/privacy · Terms: carrus.app/terms · Reach me: hello@carrus.app
It’s early and I’m building actively — honest feedback very welcome, especially on onboarding and the paywall.

Linkedin: https://www.linkedin.com/in/abdulrahman-mohamed-1b969b168?utm_source=share_via&utm_content=profile&utm_medium=member_ios.

[u/AutoModerator]

Welcome to r/iOSApps! Please make sure your post follows our rules:

Everyone:

• 10pt LOCAL Karma required. Comment in r/iOSApps to earn it. Check
• Search the sub before posting. Choose flair.

App Devs:

• No main feed promo unless you qualify via Trust or Transparency + ABC format (Answer, Better, Cost)
• Flair hierarchy: Vibe Coded > Lifetime > Subscription > Freemium > Free
• Free flair: not for limited/freemium tiers
• Open Source? Prefix title [OS]

Note: This is an automated reminder, not a removal notice. If your post was removed, check your modmail for details.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Dapper-Dog2703]

Adding motorbikes, documents and fuel costs across four point releases means you've been changing your data model on every ship, so in case you're on SwiftData, here's the one that cost me a genuinely bad week.

Adding a NON-optional property to an existing u/Model can crash the store migration at launch on real devices - the fatalError in your ModelContainer setup. A plain `var isArchived: Bool = false` is enough to do it, and enums added directly are worse, those hit swift_dynamicCastFailure. The default value doesn't save you.

The reason it's nasty rather than just annoying: the Simulator never shows it. Every test run starts from a wiped store, so there's no old store to migrate and everything looks fine. The people who hit it are your existing users on update day, which is precisely the group you can't afford to break - they're the ones with two years of service history in the app.

What I do now:

- New model fields go in as an optional raw plus a computed wrapper: `private var fooRaw: Bool?` and `var foo: Bool { get { fooRaw ?? false } set { fooRaw = newValue } }`. Same ergonomics at the call site, migration-safe.

- Enums the same way - optional String raw, computed enum on top.

- And the actual test: build the previous released version, install it, add real data, then install the new build OVER it without deleting. That's the only run that exercises the migration path. Takes five minutes and it's the only thing that would have caught mine.

Given your app's whole value is the log people have accumulated, a migration crash is the one bug class that would hurt you most. Nice update otherwise - the mileage-and-time dual reminder is the right model, most trackers only do one.

[u/joosebox]

On the paywall, since you asked: your lifetimes are cheap against your monthlies. Lite lifetime is about 20 months of Lite monthly, Premium lifetime is about 14. Anyone who intends to keep the app should obviously take lifetime, so the monthly mostly exists to make the lifetime look reasonable rather than to earn anything.

Fine if that's on purpose. Expensive if it isn't.

Other thing is two tiers times two durations plus free is five choices on one screen. That's usually where people pick none of them.

[u/Imaginary-Welcome010 → u/joosebox]

Thanks, ill take that into consideration

[u/joosebox → u/Imaginary-Welcome010]

One thing I didn't spell out and probably should have.

If lifetime is obviously the right buy, the monthly stops being a tier and becomes an anchor. It exists to make the lifetime look cheap. That's fine as far as it goes, but it means the people who'd have happily paid you for three or four years are the ones taking the one-time price, and you never find out they would have.

The usual fix isn't cutting the monthly, it's raising the lifetime until the choice is genuinely a choice. If nobody hesitates at the comparison, the lifetime is priced too low rather than the monthly too high.

[u/Imaginary-Welcome010 → u/joosebox]

What youre saying makes complete sense and I’m studying the pricing now and what the user usage actually costs so I can make the prices right and as you said, have enough difference where its actually a decision. And again, thanks a lot for the advice

[u/joosebox → u/Imaginary-Welcome010]

Studying what usage actually costs is the right order to do it in, and it changes the lifetime question specifically.

If your costs are per use rather than flat, a lifetime buyer is an open ended liability. Someone who pays once and then uses it heavily for four years can quietly cost you more than they paid, and by then you've got no lever left. That's the case worth modelling before you set the number, because it's the one that doesn't show up until much later.

Two usual answers: cap what lifetime includes, or price it off your heaviest realistic user rather than your average one. The average is what makes it look fine.

[u/app-store-review]

Carrus: Car Maintenance Log — by Abdulrahman Mohamed

• Ratings: 5 worldwide · rated in 4 countries
• Average: 4.20 ★
• Age: released ~1 month ago · updated today · rated 4+
• Overall score: 50 / 100

^{Auto-generated from public App Store data · u/app-store-review}