State of the SwingTradeBot Mobile Apps
Earlier today someone asked me: "you ever thinking of updating your android app?". Here's the TL;DR answer:
No, the mobile apps have been abandoned. They'll work as is for as long as Google and Apple will keep them in their app stores and the device operating systems are compatible.
There's really no reason to use the apps, aside from push alerts. And I'm planning on adding push alerts to the website, now that Apple has finally allowed them on Progressive Web Apps.
A little more context around my answer:
- From day 1 I built the website to work on mobile devices. Despite people asking, I saw no reason to create a separate mobile app until I added intraday alerts in March of 2018. That sole feature is what pushed me to build mobile apps so that I could send push notifications for the intraday alerts.
- One huge downside to having mobile apps is having multiple codebases, which is a MAJOR time sink. Why should I rewrite the same functionality 2 or 3 times when I could just write it once (for the website)? Not to mention subjecting myself to all the App Store shenanigans.* (see below)
- Another reason I decided to make apps was that I found a system that would allow me to write that mobile app once and then generate separate Android & iOS apps. So I'd *only* have two codebases to maintain instead of three.
- The website has a lot more functionality than the apps. It was never part of my plan to recreate everything inside of the mobile apps. The apps were just an extension of the site.
- I haven't updated the iOS mobile app in years (since December 2019) because Apple has restricted me from doing so! I Their app store rules are an ever-moving target and I refused to do what they wanted. I could write a book about Apple's ridiculous App Store rules... (see below)
- As a user I like mobile apps, as a developer I'm much less of a fan* (see below)
- In the coming weeks I will be rolling out a Progressive Web App (PWA) as a replacement to the current mobile apps. That will allow people to "install" SwingTradeBot on their mobile device with no app store in the middle. Then people can opt in to receiving push notifications.
- The current apps will continue to work until Apple/Google removes them or makes an operating system change which makes them stop working.
I think that a PWA is a good middle ground. The site will still be able to send push notifications and I will be able to focus on maintaining & adding features to a single codebase. I would have gone the PWA route initially except that for over a decade Apple refused to allow PWAs to receive push notifications. They've recently allowed push notifications -- most likely caving to pressure from anti-trust cases.
P.S.
* The current app store ecosystems -- especially with respect to Apple -- are essentially traps for developers (and users). Developers have to give way too much control to Apple (and less so to Google). You can't even send out a simple bug fix without going through their review process. And you never know how long the review will take or if it will be rejected for who knows why. For example, the last bug fix I submitted had nothing to do with subscriptions and my subscription code hadn't changed since the app launched. But the reviewer noticed that Apple's subscription rules had changed & therefore refused to let me release the bug fix until I totally rewrote my subscription code to include Apple's subscription system (which would give Apple a 30% cut of any subscriptions via their system).
In fact, the first time (in March 2018) I submitted the app Apple rejected it solely because I had a link to my site's subscription page. I had to put in some code that removed the link from the "subscribe here" text for iOS in order to get the app accepted. At that time & for the next 21 months Apple was fine with me having subscriptions via my website as long as I didn't link to my subscription page (which is straight up BS!). By December of 2019 their rules had changed to "if you provide subscriptions anywhere, you must also offer subscriptions via Apple's subscription system". For me that was a bridge too far for a couple of reasons:
In fact, the first time (in March 2018) I submitted the app Apple rejected it solely because I had a link to my site's subscription page. I had to put in some code that removed the link from the "subscribe here" text for iOS in order to get the app accepted. At that time & for the next 21 months Apple was fine with me having subscriptions via my website as long as I didn't link to my subscription page (which is straight up BS!). By December of 2019 their rules had changed to "if you provide subscriptions anywhere, you must also offer subscriptions via Apple's subscription system". For me that was a bridge too far for a couple of reasons:
- I'd already bastardized my subscription code to allow for PayPal subscriptions. What started as a nice, clean Stripe-based subscription system became more complicated by adding PayPal. Now Apple wanted me to add a third option and Google was threatening the same thing. So I'd have had to offer, manage & support 4 different subscription systems. That's a lot of unnecessary complexity & overhead.
- Apple wanted 30%(!!!) of the revenue for providing the same service that I pay ~3% to Stripe & PayPal.
Another knock against app stores is that they have terrible discoverability, which then entices developers to pay Apple to advertise their apps within the store. So to be in the Apple App Store a developer has to:
- Pay $99/year to be in the developer program
- Give Apple a 15 to 30% cut of revenue
- (optionally) Pay Apple for promotion so people can actually find your app
Recent Comments
- TraderMike on Canadian Depositary Receipts
- Cos3 on Canadian Depositary Receipts
- TraderMike on Canadian Depositary Receipts
- TraderMike on Canadian Depositary Receipts
- Cos3 on Canadian Depositary Receipts
From the Blog
Popular Now
Featured Articles