I have a dilemma - to support Apple iOS or Not
Hello IH,
For those of you that don't know, I am working on a simple and affordable cross platform crash monitoring service primarily aimed at solo developers and small startups.
I am working on a new release which will mean it will support the following programming languages/platforms
- Android (Java and Kotlin)
- C# (.Net Framework and .Net Core)
- C++
- Python
- Ruby
- Javascript
Part of this release was to support developers on iOS but I am wondering, should I, as I'm not sure whether its worth the effort and the cost.
I'm not a fan of apple anyway and have always avoided but thought making this type of service, and the fact that I am supporting most of the more popular languages that are in use today so felt that, that means I need and shout support Apple.
This is where my dilemma is. I've investigated Apple development, even gone as far as buying a second mac book pro. I have the basics working where its initialising with the service, but now starting on actually generating the crash request (pretty much the most important part), I've hit a problem.
Part of the crash requests, that I do from every other single language, is to generate a stack trace when an exception is raised. In Swift, the stacktrace is full of memory addresses so its pretty much unusable for a human to read.
I've investigated this and from the looks of it I have to symbolicate the app, and that is done by generating a dsym file, but this is only generated when an archive is generated but this can only be done if I'm connected to a physical iPhone or iPad device, which I don't have nor do I intend to get one if I can help it.
I've already spent £200+ on the mac book I don't want to buy an iPhone on the off change it might be a success, and if not I've thrown a load of money at it and got nothing in return.
I've got 3 options that I can
- Continue making a library, but not support stack traces, this means I can't tell the user in the crash the class, method or line number that triggered the crash.
- I bite the bullet and buy a second hand iPhone/iPad and then hopefully I can continue.
- I don't bother and maybe in the future when/if the service becomes a success I can then buy what I need to support Apple at some point in the future.
Option 1 seems to be the worst option, if I can't provide stack traces, class names and line numbers in a crash report, what's the point of having a crash report.
Has anyone else been in a similar situation and/or have any advice?
Thanks
Chris
Worth mentioning how competitive the ecosystem on iPhone is anyway. Firebase Crashlytics works really well and is used by most developers by default.
It might be an uphill battle on converting existing iOS coders from Crashlytics, so it could be good to wait until your current customers start building up demand for your tool to expand to iOS since you'll have the added value of being an all-in-one source of crash reports.
I vote 3 🙋♂️
That's a very good point, I've been leaning towards option 3 myself.
It depends upon your specific niche. The vast majority of our customers are on Apple products (higher tier income website owners) and based around our analytics, not supporting iOS or Mac would lose us around 60% of our client base.
Yea that's a tricky one for me to determine at the moment. I'm not targeting a specific platform, just various developers who might be working on various platforms/programming languages and then the data from those platforms/languages are then viewable on the website, so not supporting apple wouldn't lose me customers (I don't have any yet) but just wondering whether it might put people off to think its not a proper service as I can support language x, y and z including Android but I exclude apple which is also a big market player in the mobile world.
As iOS is just a segment of your market, I’d push ahead with the others and see how that goes. Chances are you could settle on one of those other “verticles” anyway. That is, you might decide that the size of the JS market is large enough and make the best tools for that rather than sub optimal tools for a broader range of languages. Horizontal markets mean you have to be everywhere, which you might be able to expand into once you conquer a segment and generate enough revenue to justify the upfront and ongoing expenses.
Its not a specific tool for a platform, its just a way of sending crashes/errors from multiple platforms into one service, but I am leaning towards not implementing apple yet and see how it goes.
My main concern though is as I'm supporting Android, as well as other common languages, does it then seem odd that I am then not supporting apple which is another popular platform
Gotcha. Well, it seems to me that getting comfortable with not being comfortable and not knowing and not being sure, and having concerns goes with the territory of doing your own thing. Embrace it, move forward and test the water seems like a sensible approach to me. If you get questions about Apple, or not, you’ll learn something! 👍
Yea I am thinking not to worry too much about Apple for the time being. See how it goes and if there's a lot of demand for it, it shouldn't take too long to build once I get everything I need.
If money is the main issue I'm sure you can borrow an old iphone from a friend? Or go for a dirt cheap option at a used electronics store.
I haven't looked yet, but I don't think there's such a thing as a cheap 2nd hand apple, they seem to hold their value pretty well. The mac book I bought which was 200+ is a 2011 model was the best I could find as didn't want to spend a fortune. Been giving me some headaches because of its age though.