remove iphone platform target

[redFrik]

Purpose and Motivation

removes the outdated iPhone platform target.

although i left two places intact...

• the SC_AUDIO_API_COREAUDIOIPHONE code defined in SC_CoreAudio.cpp and SC_CoreAudio.h
• the feature to exclude class library directories named "iphone" in SC_Filesystem_macos.cpp, SC_Filesystem_unix.cpp and SC_Filesystem_win.cpp

Types of changes

To-do list

• [ ] Code is tested
• [ ] All tests are passing
• [x] Updated documentation
• [x] This PR is ready for review

[capital-G]

Thanks for the PR, I think this helps to move the codebase into a more manageable state.

Could you apply the formatting rules to the commit, b/c w/o it the builds and tests wont be triggered (see https://github.com/supercollider/supercollider/commit/e010bc729892bdeed520365c9dcbf75211f104d3#commitcomment-156558258)

although i left two places intact...

• the SC_AUDIO_API_COREAUDIOIPHONE code defined in SC_CoreAudio.cpp and SC_CoreAudio.h
• the feature to exclude class library directories named "iphone" in SC_Filesystem_macos.cpp, SC_Filesystem_unix.cpp and SC_Filesystem_win.cpp

IMO it wloud be fine to delete those as well, or are there reasons to keep them around (aka when would be the moment to delete it if not now?)

[redFrik]

when would be the moment to delete it if not now?

good point! let's remove the SC_AUDIO_API_COREAUDIOIPHONE code.

although the ignore "iphone" directories feature i would think is best to keep. maybe someone has some old class library code that relies on this - i mean old sc classes specifically for the iPhone that shouldn't be included e.g. classes that used the AccelerometerX UGen.

[dyfer]

In the past I've had a dream of reviving SC on iOS. Could I get some time to check whether any of this may still work?

[adcxyz]

In the past I've had a dream of reviving SC on iOS. Could I get some time to check whether any of this may still work?

would be lovely if it did revive in some form :-)

[redFrik]

would be so fun to have this possibility again yes. (still have a few old iPods Touch (2&4 gen) here with sc installed (Cocoa version 3.3.1)).

but then the name of the target should be "iOS" and not "iPhone" right? so most of this PR is still relevant.

[dyfer]

most of this PR is still relevant.

I disagree.

This PR removes the actual code that was once working on iOS AFAIU, before it was called iOS. It's true that we don't know how much of it still can be made to work, but once we remove it, it will be tricky to get it back, as the codebase gradually changes and it won't be easy to just revert a commit.

It will take some time to try getting this working again in some form, but right we'd be better spending time to get SC 3.14 out.

IMO this PR should only remove the readme files, as they indeed don't contain any relevant information and are outdated.

(still have a few old iPods Touch (2&4 gen) here with sc installed (Cocoa version 3.3.1)).

Wow! Did you make these builds?

[redFrik]

ok, if you want to keep the code we close this PR. no problem.

i personally just can't see it being of much use. must be around 15 years since it last could be built. sc, iOS and Xcode have all evolved. maybe the SC_AUDIO_API_COREAUDIOIPHONE parts could be of interest, and that's why this PR originally kept them.

( iirc, one could get a free Apple developer account, build sc and install it on any iDevice - for friends - as a test app. but one couldn't distribute or send it to someone. had to physically connect, built with XCode(3?) and install onto a device with your app dev ID. else there was a timeout or something... also was never distributed on the AppStore because of licensing issues. so yea, people were building the sc iOS app themselves. and jailbreaking was a thing too. my iPods are running iOS from v3 up to 6.1.6. i also remember installing and using sc on 1st and 2nd gen iPhones. )

so close?

[capital-G]

also was never distributed on the AppStore because of licensing issues

I thought about this and never got a real understanding why - is it a GPL issue or an Apple AppStore issue? I have some GPLv3 apps on my iPhone, e.g. lichess is GPLv3 - so it seems possible?

At the same time, wasm seems to be a 2025 replacement for a native app (i.e. scsynth is already running on android and iOS) and if one would code a native app in 2025 one would probably use flutter or wasm/webgpu in order to be able to run on all platforms natively? I don't think that there is a need for Apps anymore in 2025 (at least if dev-resources are limited) - if e.g. browser restrictions become a problem (hello iOS) it is still possible simply write a web-wrapper app with elevated privileges.

edit: I'd still vote to remove this - IIUC nobody has done anything with this for 15 years, it is certainly not working on most recent iOS, so although this is a really delightful idea and code, it seems more a burden to have this code around if no one maintains it for 10+ years. If people want SC on iPhone they should give the wasm PR a review ;)

[dyfer]

wasm seems to be a 2025 replacement for a native app

Is this really a viable option for low-latency audio and native performance? Especially on resource-constrained devices? Note that there is also a plugin for reading accelerometer data and other misc functionality that we would be removing here.

it seems more a burden to have this code around

What is the burden, really? It seems more cosmetic to me. I don't recall particular issues where this code as really in the way of something else.

iirc, one could get a free Apple developer account, build sc and install it on any iDevice

Yeah, "build sc" is the part that interests me, as it wasn't clear from the current docs how that was done. BTW I found iSuperColliderKit which seems to be a SC fork with some fixes from a few years ago (that fork doesn't have a proper git history for SC source btw...).

also was never distributed on the AppStore because of licensing issues

I thought about this and never got a real understanding why - is it a GPL issue or an Apple AppStore issue? I have some GPLv3 apps on my iPhone, e.g. lichess is GPLv3 - so it seems possible?

Yes, I also don't fully understand - maybe @joshpar has any idea about this?

---

My vote would be to re-visit removing this once/if wasm becomes a real alternative to a native app.

I still think we should remove the .md files as they really are not useful for anything and can be misleading.

[capital-G]

Is this really a viable option for low-latency audio and native performance? Especially on resource-constrained devices? Note that there is also a plugin for reading accelerometer data and other misc functionality that we would be removing here.

Native is always more performant, but the accelerometer etc. can also be accessed from within the browser through JS.

What is the burden, really? It seems more cosmetic to me. I don't recall particular issues where this code as really in the way of something else.

Personally I like to keep the code base to a minimum as it is already a massive amount of code (due to the monorepo structure). If files are not used, untested for multiple years, why keep them around? :) To me they just create noise and also makes some tasks slower (e.g. search). The code files would still be part of the repo history.

One practical problem of "unknown code" is during refactoring - e.g. I would assume that the current iPhone implementation is broken, but I wouldn't even know who to ask such a thing and if some update would require to remove it, delaying the probably necessary update (a similar thing happened to me during boost upgrade and mingw build).

My vote would be to re-visit removing this once/if wasm becomes a real alternative to a native app.

My take would be to make this more dependent if there is anybody on the horizon who would take care of this? There seems to be people who would appreciate it (me as well), but I somehow doubt people will start working on it again.

I still think we should remove the .md files as they really are not useful for anything and can be misleading.

I also think we should remove at least the md files - maybe we can bring this PR up in the next dev meeting to see what the general consensus on this is?

[dyfer]

My vote would be to re-visit removing this once/if wasm becomes a real alternative to a native app.

My take would be to make this more dependent if there is anybody on the horizon who would take care of this? There seems to be people who would appreciate it (me as well), but I somehow doubt people will start working on it again.

I'm not sure how realistic this is, but I'd like to have a go at it. Maybe we can set a reasonable deadline for this (I'm thinking something like a few months, def after 3.14 is out).

I still think we should remove the .md files as they really are not useful for anything and can be misleading.

I also think we should remove at least the md files - maybe we can bring this PR up in the next dev meeting to see what the general consensus on this is?

Yes, good idea to discuss this at the next dev meeting!

[dyfer]

It will take a few weeks before I can take a look at this code. Should this PR stay open for that time?