Semi warranted. But I teach swift to teenagers, and have set up hundreds of devices/machines with Xcode/etc at this point. Yes, it's still prone to random bugs, like most software, but with sideloading it's getting pretty darn close to plug in your phone, press Run, and It Just Works.
Even if that's true, you're still locked into Apple's world—a privilege you paid for.
If I'm snarky it's because calling this "revolutionary" is a slap in the face to the people who've spent their careers working to understand early education through computers, without the ulterior motive of said platform lock-in.
Even if you write for Windows, you'll be using APIs that only work on there (eg if you write in C++ using MFC or COM, or write using .NET and eg. find that you can only do certain things with Invoke by calling into system DLLs, which you won't be able to do on other platforms, despite the open source nature of .NET these days).
If you write for iPad, you are restricted to their iOS APIs.
If you write for Mac OS, you'll be restricted to there, as you use Cocoa.
If you write for Android, you'll be restricted to there, as you write using Android's APIs despite the existence of Java and some of its runtime. You could attempt C++ on here but the NDK is a bolt-on.
The only true solution seems to be to write in a language that is available across all platforms (C++?) using a library that works across all of them (doesn't exist), but this is non-existent as the ways the systems behave (windowing, application process cycle) is different on each platform and it would be foolish to believe that they should be the same, or that they behave in the same way.
I think we should just accept that each platform has its merits and disadvantages and stop aiming for this dream of easy cross-compatibility with little developer effort. On all platforms we have to buy the hardware, sometimes have to buy the tooling, and then have to submit our applications to the respective markets or distribution channels (even on Linux, we can't just chuck our stuff at repos, particularly if we want to sell it). Ultimately if we write for a platform, there will always be lock-in of some sort (eg why can't I run my EXE on Mac?).
To be honest, your knowledge is probably much better than mine. I just lurk hacker news and r/programming way too much for someone not in the industry.
Apple was never really open to other platforms though. I don't think they traded positions then, Microsoft evolved a bit while Apple continues with the same approach.
Yep. Apple has always wanted to control both the hardware and software, whereas Microsoft 'settled' for controlling the software on a fairly open hardware platform.
Not always. Steve wanted to, but Steve disagreed. For the Apple 2, the net effect was that it shipped with hardware schematics (everything, including the power supply) and commented ROM listings.
Even the original Mac still had fairly comprehensive documentation of parts of its hardware, if you bought the phone book edition of Inside Macintosh.
And of course, IBM didn't 'settle' for opening up the platform. Compaq and Phoenix Technologies opened it for them.
I feel like Apple was more open to alternate distribution options at the beginning of OSX, but I might be wrong in this. tvOS and watchOS have made their software distribution completely Apple lock-in, i.e. you can only do it with Apple tools, see bitcode requirements.
Apple was the last surviving company of home computers, from the likes of Acorn, Atari, Commodore, MSX,.....
All of them controlled the whole experience, both hardware and software.
By the time Apple bought NeXT (which in practice was actually the other way around), they need to attract developers back to their platform, so they played nice.
Nowadays they have plenty of money on the bank and can be back to being as they always were.
Overlooked C++. My point stands for managed runtimes. ObjC/Swift don't have to deal with the following laundry list of things the managed runtimes need to implement:
- Explicit instrumentation for null pointer checks (slow)
- Explicit instrumentation for stack overflow checks (slow)
- Explicit instrumentation for GC safe points (slow)
- Exceptions and unwinding implemented on top of cxx_throw instead of signals and setjmp/lonjmp (slow and error prone)
- Defensively generated trampolines for reflection for any thinkable parameter type permutation
There are quite a few more details that make managed runtimes under bitcode suboptimal.
Taking away things like read/write register access, signals and system APIs like setjmp/longjmp puts managed runtimes at a huge disadvatage.
Neither Swift nor ObjC (and to a large degree C++) need to solve any of these problems.
I doubt very much any of those issues will show up relevant values in a profile run, which is what actually matters, not the theoretical value of a few ms more that the user hardly notices.
There is also room for the AOT bitcode optimizations to hoist many of those checks, specially since the AOT compilation takes place at the store side with lots of resources available.
Android and Windows Phone have already proven that those issues aren't an actual issue from the user point of view, specially on the Android side if you take into account the market share.
I've worked on both RoboVM and Mono, I can tell you first hand that these are issues that are real and have high impact on performance.
Android and Windows Phone don't lock their respective managed runtimes down like Apple does lock down the likes of Mono/Xamarin. On Android you have full access to almost everything, and on Windows Phone MS has a vested interest in exposing all required features to their managed runtime. No such luck on Apple hardware.
When I started getting around computers we had to pay for everything and most of the programming languages were specific to the machine one had, way before Apple mattered at all in the home market.
Apple 8 bit computers weren't even relevant in Europe.
Ultimately, if those people with their years of understanding have done a better job of understanding the needs of teachers and pupils then Apple will fail.
If Apple doesn't fail, then those people need to have a long hard look at their careers.
Out of curiosity, how many of those teenagers come from impoverished circumstances? I find a certain irony in schools teaching things like iOS development to demographics which very likely cannot responsibly afford an apple computer or even an iPhone.
I still think it's a good thing, just that it brings a different perspective to the "walled-garden" argument against many brands/services as well as tech education as a whole.
Most of them do. We teach basic Ruby and Swift (with UIKit), certainly not "iOS development". The workshop is only over 3 days, with some homework.
The goal is not to make them the developers of tomorrow - just to expose them to programming, and light CS thinking. They don't get these opportunities at school. If they don't like it, well hey at least they tried. If they like it, then great! They have discovered a new passion they might have not found otherwise. We've been doing this for a few years now, and many of them (about 40%) have gone on to study CS or something related in college; of those, a fair number also got the motivation to go to college partly because it'd allow them to study CS.
We very much emphasize the fact during the workshop that if they understand the basics (variables, loops, functions, etc.) then they can learn any language. A big part of the pedagogy is encouraging them to try things, fail, use Stack Overflow, etc.
Gender split is basically 50/50, a fair mix of black/hispanic/asian kids with the few white kids sprinkled in.
All that said, a fair amount of them do have iPhones.
Semi warranted. But I teach swift to teenagers, and have set up hundreds of devices/machines with Xcode/etc at this point. Yes, it's still prone to random bugs, like most software, but with sideloading it's getting pretty darn close to plug in your phone, press Run, and It Just Works.