Kev Says:

[IanMc]

if I were to ask you Kev and after you've perused all of the data that you know about B4xPages and knowing that to develop first for Android and then be able later to do the same app for iPhones what advice would you give?
21:26


My advice: build it as a B4XPages app from day one, but treat Android and iPhone as two different bodies sharing the same brain.
The practical shape I’d use:

(redacted sensitive info about my own app)

Keep the main app logic shared
Touch positions, three-finger shape rules, sound mode selection, token counting, remote state, consent state: shared B4X code.

1. Keep hardware stuff behind wrappers
   Vibration, audio playback/synthesis, permissions, notifications, purchases, and networking may differ on Android/iOS. Hide those behind small platform-specific modules.
2. Use B4XViews/XUI/B4XCanvas
   Especially for the main touch pad. That gives us the best chance of reusing the look and behaviour later.
3. Do Android first, but don’t write “Android-only thinking”
   No shortcuts that make iOS painful later. Android can be the proving ground, but the code should keep asking: “would this survive B4i?”
4. Do not overuse third-party UI kits yet
   Daisy/Yoga may help later for settings and remote screens. The instrument pad should be ours.
5. Upgrade to B4A 13.5
   The code bundle feature will help me help you, and the newer B4XPages template sounds better aligned with current Android behaviour.
6. First build the feeling, then the business
   Before tokens, stores, and iOS, get the core loop lovable: touch, sound, vibration, STOP, remote consent.

So my strong advice is: B4XPages is the right foundation. Android first, shared core always, iOS later without panic.
21:26

 

[IanMc]

Another question Kev.... people have GIT repositories, is that a good thing or should we just bung it on Google Drive and access it anywhere we want... isn't that backed up by default?

Too much blurb.

Essentially if you're old and lonely like me and don't have any collaborators then GIT is an unnecessary extra layer of complexity.

Just bung the files on the big G and access them from any laptop.

As soon as your app starts to make copious amounts of money then magically you won't be alone any more!
(you'll think it's coz of your boyish good looks but it aint')

 

[aeric]

If you think Git repo is a backup then you are using it wrong.

 

[IanMc]

No of course it's also version control software such that if you have a working model and you make a change which messes it up you can quickly revert to the version that works.

 

[aeric]

There are many more about Git.
We can promote B4X if we open source our project and contribute to existing libraries.

 

[John Naylor]

I use Git for version control and auto-deployment to Railway for my Django/ReactJS systems. Following @aeric suggestion, I've added several B4X repos publicly to help promote B4X and give LLMs better training material. Since then, I've added a number of private B4X repos as well, which has been invaluable for version control on its own.

The real game-changer, though, is that I've generated a GitHub API access token and pasted it into Claude's Instructions section (not the main chat). That means I can have detailed conversations with Claude about my code without ever needing to upload files — it can pull whatever it needs directly from the repos.