Topics

BBC BASIC for iOS?

Richard Russell
 

The availability of a sort-of-working 64-bit version of BBCSDL (albeit with several unresolved issues) makes it in principle - and I emphasise in principle - possible to build an iOS edition, because iOS is (and has been for some time) 64-bit only.  However there are a number of significant complications, not least the absence of an Android-like 'back button'; BBCSDL is thoroughly dependent on that button for the 'cancel' or 'return back to where you came from' functionality (it maps to the Escape key on desktop platforms).

Typical iOS users and app developers don't necessarily see the absence of a back button as a problem because the equivalent functionality can be designed into the specific application, either as a 'button' (i.e. an icon that you can tap) or as a swipe gesture.  But that's not a good solution for a programming language like BBC BASIC: you don't want every individual BASIC program to have to include code, uniquely for iOS, to implement a button or gesture (and in any case there might not be an obvious place for a button to go, and a gesture might interfere with some other touch functionality such as scrolling).  You want the language to provide the feature in a standard way, that every BASIC program can take advantage of on every platform.

There are other problems that would have to be resolved before even an experimental iOS edition could be developed.  One is that a more modern Mac than anything I own is required to build iOS apps, and (as a non Apple enthusiast) I neither want to have to purchase such a machine nor find room for it.  In contrast Android apps can be developed and tested (in simulation) on a regular Windows PC.  Then there's the issue that iOS apps can only be downloaded from the App Store; there isn't (as far as I'm aware) an option similar to Android's of overriding the default settings to allow downloading from other sources.  And the App Store imposes conditions that it might be impossible for BBC BASIC to meet.

So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them.  Does anybody have an opinion on the desirability or otherwise of such a product, and/or any proposals for how the issues discussed above might be tackled.

Richard.

Storer, Darren
 

Hi Richard,

Apologies for remaining quiet during recent dialogue via the list - it's "that time of year" and there's a lot of battening down the hatches going on before we can all go on annual leave.

If you were to release an iOS version, I would be very happy to pay for the privilege of using the software via the App Store but I do realise that money is not a motivator for you.

How modern a Mac would you need to develop an iOS app?

On the topic of Escape keys, it's not that long ago that Apple stopped supplying keyboards with this "feature"!?!

Regards

Darren


On 19 December 2017 at 16:41, Richard Russell <news@...> wrote:
The availability of a sort-of-working 64-bit version of BBCSDL (albeit with several unresolved issues) makes it in principle - and I emphasise in principle - possible to build an iOS edition, because iOS is (and has been for some time) 64-bit only.  However there are a number of significant complications, not least the absence of an Android-like 'back button'; BBCSDL is thoroughly dependent on that button for the 'cancel' or 'return back to where you came from' functionality (it maps to the Escape key on desktop platforms).

Typical iOS users and app developers don't necessarily see the absence of a back button as a problem because the equivalent functionality can be designed into the specific application, either as a 'button' (i.e. an icon that you can tap) or as a swipe gesture.  But that's not a good solution for a programming language like BBC BASIC: you don't want every individual BASIC program to have to include code, uniquely for iOS, to implement a button or gesture (and in any case there might not be an obvious place for a button to go, and a gesture might interfere with some other touch functionality such as scrolling).  You want the language to provide the feature in a standard way, that every BASIC program can take advantage of on every platform.

There are other problems that would have to be resolved before even an experimental iOS edition could be developed.  One is that a more modern Mac than anything I own is required to build iOS apps, and (as a non Apple enthusiast) I neither want to have to purchase such a machine nor find room for it.  In contrast Android apps can be developed and tested (in simulation) on a regular Windows PC.  Then there's the issue that iOS apps can only be downloaded from the App Store; there isn't (as far as I'm aware) an option similar to Android's of overriding the default settings to allow downloading from other sources.  And the App Store imposes conditions that it might be impossible for BBC BASIC to meet.

So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them.  Does anybody have an opinion on the desirability or otherwise of such a product, and/or any proposals for how the issues discussed above might be tackled.

Richard.


Richard Russell
 

On Tue, Dec 19, 2017 at 08:41 am, Richard Russell wrote:
So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them. 
I've 'acquired' a hand-me-down iPhone (5S) from SWMBO, which has prompted me to take an interest in this topic again.  One thing I've definitely established is that iOS does not allow arbitrary code execution (it's not an App Store limitation, iOS itself prevents it) which of course means that neither BBC BASIC's assembler (not that we have one for 64-bit ARM!) nor the CALL statement and USR function, would be usable.  Considering how important the ability to run machine code is to BBC BASIC (for example some of the libraries depend on it, notably SOCKLIB and SORTLIB in BBCSDL) this is problematical.

The issue of SORTLIB is the more easily worked around, because it is of course possible to implement the same functionality in BASIC code.  It would only run at a fraction of the speed, but it might be good enough for some applications.  There is also the possibility, in principle, of adding a native SORT keyword to BBC BASIC (many BASICs do have that capability).

I don't know of any workaround for SOCKLIB however.  SDL_net, unfortunately (and stupidly in my opinion) provides no non-blocking 'read from network' capability, which is frequently a requirement - to be able to get on with other things, or monitor for an abort, while waiting for data to arrive.  I solve that at present by performing the 'blocking' read in another thread, but of course the only way to create a new thread in BBC BASIC is to use assembler code.

So, given all that, what is the consensus of opinion on whether developing an iOS edition of BBCSDL would be worthwhile or not?  I've always argued that BBC BASIC without an assembler isn't truly BBC BASIC, but you can't fight Apple!

Richard.

Richard Russell
 

Playing with the iPhone (I realise it's rather like communing with the Devil!) has at least answered one question: what to do about the absence of the Android 'back' button.  Other apps which require that functionality, including Apple's own 'Settings' app, seem to have established a convention of providing a back button in the top-left corner (sometimes bottom-left, such as in Safari) consisting of a simple 'chevron' or less-than symbol.  It shouldn't be difficult for BBC BASIC to overlay a similar button; there will be occasions when it obscures something important but experimentally rotating the device from portrait to landscape usually moves it out of the way.

Richard.

Richard Russell
 

On Tue, Feb 27, 2018 at 04:33 am, Richard Russell wrote:
I don't know of any workaround for SOCKLIB however.
This is proving to be less of a problem than I feared.  I've today experimented with allowing the 'read from network' function to block, and so long as I read relatively small packets - and have a relatively fast internet connection - the effect on the performance of 'banner.bbc' and 'Ceefax.bbc' is not too serious compared with the version of socklib using assembler code.

Richard.

Storer, Darren
 

Hi Richard,

Just a quick thought about the iOS back button challenge... Some of the apps that I use implement an Android style back button functionality by using the "undo" feature that was introduced a few years ago. If you are entering text into an application such as iMessage, and you make a mistake, you can "undo" the input by shaking the iPhone from left to right rapidly.

You can disable the iOS undo function (accessibility settings) but it is enabled by default.

Currently I am snowbound in Edinburgh, without an Android phone to test the APK routine (my mistake) but I have a couple of iOS devices with me if you need any testing.

Hope this helps

Darren

On 28 February 2018 at 23:15, Richard Russell <news@...> wrote:
Playing with the iPhone (I realise it's rather like communing with the Devil!) has at least answered one question: what to do about the absence of the Android 'back' button.  Other apps which require that functionality, including Apple's own 'Settings' app, seem to have established a convention of providing a back button in the top-left corner (sometimes bottom-left, such as in Safari) consisting of a simple 'chevron' or less-than symbol.  It shouldn't be difficult for BBC BASIC to overlay a similar button; there will be occasions when it obscures something important but experimentally rotating the device from portrait to landscape usually moves it out of the way.

Richard.


Richard Russell
 

On Fri, Mar 2, 2018 at 02:03 am, Storer, Darren wrote:
Some of the apps that I use implement an Android style back button functionality by using the "undo" feature that was introduced a few years ago.
I didn't know about that (only having any experience of an iOS device for less than a week) but I suspect it's a moot point because I don't think that gesture is exposed by SDL2.  I'm pleased with my 'soft' button, it uses the same chevron-style icon as those in Settings and other built-in apps, and being positioned in the top-left corner of the screen rarely obscures anything critical (I've made the background slightly see-through too!).

The only significant issue is that the button doesn't show in 3D programs like 'teapot' and 'world', because OpenGL has taken over the display, but you can still get the 'back' action by tapping where the button would have been!

Richard.

Richard Russell
 

On Fri, Mar 2, 2018 at 02:03 am, Storer, Darren wrote:
I have a couple of iOS devices with me if you need any testing
It's far too soon to think about that, and anyway Apple don't allow ad-hoc distribution of apps so there's no way I could let you have it.  There's some scheme whereby a developer can set up a group of testers, who have to be individually invited and registered, but even then the app only runs if you have an internet connection to 'authorise' it, and after three months (I think) it times out and stops working anyway!

If you know of any workaround for letting people try apps that aren't on the App Store - short of jailbreaking the device of course - I would be very interested.

Richard.

Rob McKay
 

I'm a registered iOS developer, with a reasonable modern MAC, so if you need anything compiling and / or submitting to the app store on your behalf, please let me know.

I've checked the info I have and it looks as though you are correct about the testers. It is different if you physically load the software directly from xcode. It then (seems) to last as long as the certificates are valid.

Richard Russell
 

On Fri, Mar 2, 2018 at 08:39 am, Rob McKay wrote:
if you need anything compiling and / or submitting to the app store on your behalf, please let me know.
Thanks.   My assumption is that I could never get BBC Basic to pass App Store verification because of its status as a general-purpose programming language that can easily crash the process (e.g. by using an indirection operation at an inappropriate address).  Even with iOS apps being sandboxed, Apple seem paranoid about what they are allowed to do (e.g. the prohibition on executing arbitrary code, which you'd think wouldn't be harmful in a sandbox).

If, from your experience, you think there is a chance of getting BBC Basic onto the App Store I would certainly value any advice you can give.  At the moment I'm fiddling with it for my own interest, and not expecting to be able to distribute it other than under the restrictive and time-limited conditions of a testing regime.

It is different if you physically load the software directly from xcode. It then (seems)
> to last as long as the certificates are valid.

I don't think it would be very popular with users if the only way they could get BBC Basic onto their iOS device was to send it to me (along with the unlock code) so I can install the app locally from Xcode!  And having to do it again every time there is an update....   It would certainly be a novel marketing technique.  :-)


Richard.

Rob McKay
 

Hi Richard,

I believe that it would be possible to get BBC Basic to pass the App Store verification.

I think that there are two things that need considering:

1. BBC Basic as an application programming environment

and

2. Applications build using BBC Basic

I believe that section 3.3.2 of the Apple Developer Program License Agreement (19/09/2017) covers both of these.

3.3.2 Except as set forth in the next paragraph, an Application may not download or install
executable code. Interpreted code may be downloaded to an Application but only so long as
such code: (a) does not change the primary purpose of the Application by providing features or
functionality that are inconsistent with the intended and advertised purpose of the Application as
submitted to the App Store, (b) does not create a store or storefront for other code or
applications, and (c) does not bypass signing, sandbox, or other security features of the OS.

An Application that is a programming environment intended for use in learning how to program
may download and run executable code so long as the following requirements are met: (i) no
more than 80 percent of the Application’s viewing area or screen may be taken over with
executable code, except as otherwise permitted in the Documentation, (ii) the Application must
present a reasonably conspicuous indicator to the user within the Application to indicate that the
user is in a programming environment, (iii) the Application must not create a store or storefront for
other code or applications, and (iv) the source code provided by the Application must be
completely viewable and editable by the user (e.g., no pre-compiled libraries or frameworks may
be included with the code downloaded).
I think that for Applications built with BBC Basic you could have an application bundler application similar to your utility to package things for Android which is how I believe xamarin applications for iOS are created.

For the IDE part of BBC Basic this is allowed by the second paragraph and could be published using an application bundler tool.

Regards,

Rob

Richard Russell
 

On Sun, Mar 4, 2018 at 01:40 am, Rob McKay wrote:
I believe that it would be possible to get BBC Basic to pass the App Store verification.
That's interesting, and deserves more careful study.

an Application may not download or install
>
executable code. Interpreted code may be downloaded

That shouldn't a problem, indeed it seems a superfluous statement because iOS does not allow an app to execute arbitrary code (whether downloaded or created within the app; it is blocked at a very low level).   BBC BASIC programs and libraries are of course interpreted so that is covered.

> no more than 80 percent of the Application’s viewing area or screen may be
> taken over with
executable code, except as otherwise permitted in the Documentation

It isn't clear whether "executable code" in this context includes interpreted code or not, and what do they mean by no more than 80% of the screen being "taken over"?  If they mean - as I suspect they do - that it must be obvious that the output is from the program being executed and not from the app itself, BBC BASIC will definitely fall foul of this.  It's fundamental that a running BASIC program can take over the entire screen (it's even technically unavoidable when it comes to OpenGL/3D programs).

Do you agree with my interpretation, and if so do you think there is some way around this restriction?

I think that for Applications built with BBC Basic you could have an application
> bundler application similar to your utility to package things for Android

It was only possible for Android because APKs have been 'reverse engineered' (Android is Open Source anyway) and a utility - APKtool - is available to hack them.  I wouldn't have the first idea how it could be achieved for iOS, but obviously it would be very significant if it can.  Is this something you could help with?

Richard.

Richard Russell
 

BBC BASIC runs shockingly slowly on the iPhone 5S, worse even than my slowest and cheapest Android tablet!  I doubt that the iPhone's CPU is very slow (although Apple may be throttling it to spare the battery, supposedly) so my suspicion is that it's the difference between GCC - which is what the Android edition is compiled with - and Apple's Clang compiler.

The relative merits of GCC and Clang are hotly debated, but one significant difference is that GCC supports 'register variables' whilst Clang does not.  Register variables are documented as being particularly useful in language interpreters, so that might be a significant factor.  I've selected the 'fast, aggressive optimisation' option in Clang to squeeze as much out of it as I can, but it's still slow.

There's a detailed comparison of benchmarks here but it may be that the BBC BASIC interpreter is not typical.  Either way, it's out of my hands (I might, in principle, be able to build the iOS app using GCC but I'd rather use the 'official' Apple toolchain).

Another possible contribution to the difference is that the Android edition of BBC BASIC is 32-bit and the iOS edition is (necessarily) 64-bit.  However if the relative performance on a PC is any guide (and of course it's a totally different CPU family so it may not be) there isn't much to choose between them as far as speed is concerned, and the 64-bit version is even faster on some tests (probably because of having more registers).

Anyway, mobile devices are getting faster with every generation so I'm not particularly concerned, but if and when we find a way to let people try the iOS version of BBC BASIC (and I expect it's going to be via the 'testers group' route, with the 3-months time expiry) don't be surprised if it's rather slow.

Richard.

Richard Russell
 

On Sun, Mar 4, 2018 at 04:06 pm, Richard Russell wrote:
BBC BASIC runs shockingly slowly on the iPhone 5S, worse even than my slowest and cheapest Android tablet! 
An interesting discovery is that it's the graphics that are slow, not the actual computational speed, which is about what you would expect it to be.  So I can't blame Clang for the slowness; whether the GPU is the bottleneck I'm not sure.  More investigation needed!

Richard.

Rob McKay
 

I believe that xamarin uses some of the tools which come with xcode to package applications so a similar solution could be found for BBC Basic.

There is a swift playground application for iOS which may provide some clarification about the
 
> no more than 80 percent of the Application’s viewing area or screen may be
> taken over with
executable code, except as otherwise permitted in the Documentation

I seem to recall (but cannot confirm) that when a program is "run" in a programming environment that it may take over the whole screen so long as it provides a way to go back to the programming environment.

Regards,

Rob

Richard Russell
 

On Mon, Mar 5, 2018 at 01:33 pm, Rob McKay wrote:
I seem to recall (but cannot confirm) that when a program is "run" in a programming environment that it may take over the whole screen so long as it provides a way to go back to the programming environment.
I can (and do) make sure that the example programs I supply with BBC BASIC have an easy means of returning to the 'IDE', but I have no control over programs written - or downloaded - by the user.  If Apple expect me somehow to modify BBC BASIC so that it's no longer a 'general purpose' programming language, by for example making it impossible to disable the 'escape' action, I'm not going to do that.

I suppose at some point the only thing to do will be to submit it for App Store verification, but assuming that I am honest with my description I think it's almost certain that it will be rejected.

Richard.

Sandy McAfee
 

Dear Richard

I would view this as highly desirable. Alas I have nothing to offer in terms of solutions or proposals.

Sandy


On 19 Dec 2017, at 16:41, Richard Russell <news@...> wrote:

The availability of a sort-of-working 64-bit version of BBCSDL (albeit with several unresolved issues) makes it in principle - and I emphasise in principle - possible to build an iOS edition, because iOS is (and has been for some time) 64-bit only.  However there are a number of significant complications, not least the absence of an Android-like 'back button'; BBCSDL is thoroughly dependent on that button for the 'cancel' or 'return back to where you came from' functionality (it maps to the Escape key on desktop platforms).

Typical iOS users and app developers don't necessarily see the absence of a back button as a problem because the equivalent functionality can be designed into the specific application, either as a 'button' (i.e. an icon that you can tap) or as a swipe gesture.  But that's not a good solution for a programming language like BBC BASIC: you don't want every individual BASIC program to have to include code, uniquely for iOS, to implement a button or gesture (and in any case there might not be an obvious place for a button to go, and a gesture might interfere with some other touch functionality such as scrolling).  You want the language to provide the feature in a standard way, that every BASIC program can take advantage of on every platform.

There are other problems that would have to be resolved before even an experimental iOS edition could be developed.  One is that a more modern Mac than anything I own is required to build iOS apps, and (as a non Apple enthusiast) I neither want to have to purchase such a machine nor find room for it.  In contrast Android apps can be developed and tested (in simulation) on a regular Windows PC.  Then there's the issue that iOS apps can only be downloaded from the App Store; there isn't (as far as I'm aware) an option similar to Android's of overriding the default settings to allow downloading from other sources.  And the App Store imposes conditions that it might be impossible for BBC BASIC to meet.

So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them.  Does anybody have an opinion on the desirability or otherwise of such a product, and/or any proposals for how the issues discussed above might be tackled.

Richard.