A nudge to the right direction

Creator Lounge
1

My first post, please be gentle.
This is going to be a long one so please bear with me.

I have been working on my app on X for a few days now. The general idea of the app is that users use the app to view, rate, and provide feedback to one another. The app basically has three screens. The splash/login screen, an account setting screen, and the profile page screen where rating and feedback scores of the user are visible.

Now, I have managed to finish 80% of the app layout for all three screens, and I am now trying to make all the functions work. Searching through the community for the solutions I need, I found that most of the solutions only work on Classic. Facebook/Google login, graphs, and some other extensions, just to name a few.

Because of this I am now unsure about how to proceed. Should I continue working on X and just try to make it work? Or should I start over in Classic? I do really want my app to work on both iOS and Android. Your inputs are very much wanted and appreciated.

p.s. Lounge is the closest category I can think of for my concern. I do apologize if its the wrong one.

1 Like
2

Hard to tell. If I could predict the future, I would not be here typing this answer, I would be spending the millions I would get daily knowing exactly how the stock market would change the next day.

The problem is complex.
On the one hand, X is not up to spec with Classic, and on the other hand, Thunkable claims that they will discontinue support for Classic, and that the API 28 compiler (assuming that it eventually gets fixed, since it is buggy) is likely the last iteration.
However, with Classic, you can actually download your aia and upload it in App Inventor, AppyBuilder or Kodular and continue development/deployment from there with just a few corrections and adjustments. With X, you cannot get anything out of the system for safekeeping or to migrate – and that is assuming that there would be something compatible out there to migrate to, which there isn’t.

On the other hand, App Inventor is supposed to work on adapting their development environment so that it could also target iOS. It is not happening fast, the note claimed they the envisioned it for “summer 2019” which officially ends this coming Monday September 23rd (so don’t hold your breath).
Those in the know claim that the problem is due to the lack of cooperation from Apple, which likes to control everything (they insist on you developing using their environment, using their computer language, on an Apple computer, distributed only through their App Store, on their conditions, with you paying a yearly fee. With Android, you can even side-load; that is, install an app from a site that is NOT play.google, if you know and accept the risk.)

But if one day, Apple can be reasoned with, and that App Inventor is allowed to produce files that could target an iPhone, then all App Inventors derivatives (Kodular, AppyInventor, and even Thunkable Classic, if Thunkable decides to not play the heavy and kill Classic) would most likely ALSO become Apple compatible.

If Apple is that unenthusiastic now with the App Inventor porting, what is to say that, 6 months from now, they would decide that X is not to their liking anymore and basically kill it off for iOS? Apple even implemented planned obsolescence in their own products (and is being sued for that) in order to force users to upgrade to their latest models, so it has been seen before that they can decide to be somewhat nasty and uncaring.

If you insist on having iOS support, I would suggest you also investigate the other possible approaches, that of apps running as browser clients. There is one web for everyone, and no such thing as web pages that would only load for Windows, or only for Apple, or only for Android, right?
That means if your app is running using the components of a browser – any browser, since they ALSO have to be standardized, be it FireFox, Chrome, Opera and what not – then you immediately become portable.
The downside is that tools for developing that kind of applications do not have the nifty “click this number 5 tile to the end of this assign to variable tile” approach, and you would have to type code in the old fashion way.
That is my two penny’s worth.
For the record, those alternate development environment able to support Apple and Android are Apache Cordova (formerly known as PhoneGap), Enyo, Microsoft’s Xamarin, Facebook’s React Native, and Google’s Flutter.
There may be others that I haven’t heard of.
And I am just about to proceed with evaluating them, so would be hard pressed to recommend one over the other, although would most likely start looking into Flutter, primarily because it is the one most likely to be mercilessly optimized.
But that is just me.

(as for your question being long and needing someone to ‘bear’ with you, how is THIS for an answer???)

3 Likes
3

Thank you very much for taking the time to reply!

I really really appreciate the breakdown, it helped me understood all the options that I have and how to proceed. I will still continue work on X and just finish the app, that way I can get a feel of how well the app is built and also be able to have my friends test it and give feedback. I will definitely be looking into browser client based apps, as this seems to me the most logical approach if I want both iOS and Android.

I look forward to seeing your input on alternate development environments on a personal site you may have? Anyways, again, huge thanks for the reply. The reply did not feel long as it was explained beautifully and it was just the right nudge I needed.

Cheers!

4

I do not currently maintain a web site of my own, and do not entertain the notion of being on ‘facebook’, that somewhat limits the availability of eventual environment comparison.
That said, if I start looking into Flutter, and find out that it does what I want, I may not even bother looking further, even if one of the alternate could be better. The issue is that everyone and their dog is likely to launch new computer languages and environment, and the existing ones could go through new revisions, so this year’s winner could be next year runner up anyway. Should anyone bother constantly re-evaluating new releases, let alone submit to a complete porting to a new environment just because the buttons style of package A is now better looking that those in package B?
Even when looking at the existing alternatives to Classic (which I actually did review somewhat a couple months ago), that is Kodular and AppyBuilder, one could wonder what do they offer extra?
They have more components, but if you do not absolutely need them, are they pertinent?
AppyBuilder and Kodular, for instance, have a component to access the pressure sensor that Classic lacks. If your app is an altimeter, that could justify switching over. But if your app does not need it, what would the point be?
For the record, one of the most senior member on this forum (@Peter_Mathijssen) put together a spreadsheet comparing those App Inventor clones: https://docs.google.com/spreadsheets/d/1GDgfFzRt42dJXeoHKIWWdSlMczZkefqDOoDBAFM7v14

And this ( http://doesappinventorrunonios.com/ ) shows the current progress of App Inventor in targeting iOS. It appears to be 90 or even 95% done, but how much time will the remaining 5 or 10% take? Is it worth waiting?

And that is the frustrating bit. If I decide to transfer all my development to a different environment, work like crazy for a full month just to find out that AI is now go for Apple, I would feel like a fool. But if it takes 8 months before Classic or Kodular or AppyBuilder implement the same, the story is quite different…

1 Like