Will they include a lesson on how to make Byte set up a provisioning profile in itunesconnect and install a code signing key in your local keychain and and enter the MAC address of his tethered device into developer.apple.com and then hopefully, just maybe XCode will allow you to run what you wrote?
No. Because it's not relevant to working with code in swift playgrounds on an iPad. It's not even relevant to working with XCode and hasn't been for some time now. I'd never say XCode 'just works', but it currently works better than it did. Especially around provisioning and most especially around just getting some code to run on a device. I well remember that WTAF moment when I plugged my first iPhone into my first mac and realised that just to run hello world I would need to give Apple money and then do those things that you said. Doesn't work like that anymore.
The other day I helped a new iOS dev to get going, we signed him up for our company Apple Developer account and then tried to log him in to XCode. We got an error like 'your session timed out'. We tried everything we and Google could come up with to no avail. Next morning it just worked.
Sure, an anecdote. But my experience with XCode and provisioning so far is that I stumble on different, unexpected weirdnesses like these, over and over again.
I am not surprised and believe your anecdote without hesitation. XCode is better along multiple dimensions than it was a few versions back, but is still a crawling horror. Even so, the workflow (weird bugs and all) around provisioning is nowhere near as awful as it used to be. A small mercy, to be sure.
Correct me if I'm wrong (it's been a while), but I'd say you never needed to give Apple money to run your code on your device. You just needed to create a free developer account. The payment option was to publish apps in the AppStore etc.
Thanks guys. Actually I added the "correct me if I'm wrong" part because I suspected this could very well be the case :) You know, we're getting old, we forget the worst parts...
Free developer accounts are fairly new, and they are an even greater hassle than the paid accounts. Both the device and the Mac need to be online (so impossible to develop on the train with spotty internet), you need to manually unlock every single app in the device settings, there's a very low upper limit of apps (8 or so?) you're allowed to install on your device. If you have an Xcode project with many targets (e.g. sample programs), you need to manually delete apps on the device before you can deploy/debug new ones. Also, for all provisioning scenarios you'll now have to set a 'development team' per target (not just once per project), and this needs to happen, there's no default. This is especially fun with cmake, each time after generating an Xcode project you need to manually go into the Xcode project settings and fix the development team on each target.
It's a mess and I don't see why it has to be so complicated for development.
Wait a second, if I got it right you use an external tool to generate Xcode project?
So basically the external tool don't properly set the 'development team' variable in the generated Xcode project.
May I ask how this is supposed to be Apple's fault if a third party App haven't yet been updated to meet new requirements? Did you update XCode ahead of version supported by your external tool?
Coming from scripting languages, I'm starting to learn pure Xcode/Cocoa/Swift workflow with a free account and I really don't relate to problems you are describing (but my target is only macOs for now, so I might miss the deployement hassle you describe I give you that)
The problem is not the external tool, cmake allows to set all Xcode project attributes just fine. The problem is that there is no automatic default for this one setting, the development team setting has to be manually set.
For instance, you also cannot distribute Xcode project files now which simply compile out of the box. You'll have to go into project settings first and set the development team for every single app target.
Why the development team is part of the project setting, and not simply an Xcode-wide setting in the preferences is beyond me.
As of right now, my Xcode got access to 5 to 10 team and their project. How is he supposed to know that I want my target z go to team y ? And that this target is a store account, not the usual enterprise one for other project by the same team ?
And I think cmake can add the proper account to the project too, but it's probably not well documented...
I think the proper solution would be to have a 'default team' which is filled in for each target that hasn't an explicit team set. That way, Xcode project files coming with open source projects could keep the team setting empty and would still compile and deploy out of the box.
The builds also expire after a couple of days, which is incredibly frustrating if you tell someone "Yeah I'm working on this cool project!" and they ask to see it.
Sorry buddy, this build is from last Wednesday, so all it can do is launch itself and immediately crash back to home screen.
ISTR - and ICBW because it has indeed been a while - that back in the iPhoneOS days the free account got you XCode and the simulator but you needed a paid account to be able to get an actual provisioning profile to load code on a device. But that was like 5 or 6 XCodes and 4 and some S'es iPhones ago. I might well be misremembering.
I actually did, that spend was part of an NRE package for an R&D contract and the cost was borne by the client. How it works. If the point you're making is that the additional developer fee is marginal, you are of course quite corrrect.
I'm pretty sure stevetrewick wasn't talking about this when he wrote "and realised that just to run hello world I would need to give Apple money and then do those things that you said".
If you put it that way, it's impossible to write any code and run it on any device without paying something to some company.
Quite. It's not even a huge amount considering all the other stuff you get along with it (and it was less then) but it still felt weird as I'd just come off a stint of Windows Mobile stuff (shudder) which was pretty much plug in and hack - though of course in that case you still have to give MSFT money for the dev tools. (And the host. And the devices. And the chair to sit on ...)
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.
The playground looks pretty cool but I kind of second this. I recently built something for an iPad (ad-hoc install for a client on a single device). Never developed anything in the Apple ecosystem. XCode was surprisingly stubborn and it seemed very non-rapid to set everything up. The build process was also kind of slow. Since it was a Unity Engine based up I ended up building and testing everything on Android and only pushing the final product to the iPad (and testing it on that device obviously).
For these learning environments it would be pretty awesome if there was a simple way to share the actual app. At least it seems they make it easy to share the code and a video which is a decent start.
It looks simple but it's actually about 6 different programs all stuck together.
Codesigning breaks on it periodically, and it takes days to fix.
XCode 8 has just broken this worse than any other XCode version in history. It seems to have done so by trying to automate all its requirements. So now it outputs broken bundles when I compile it. This has taken me all of today, and I'll be surprised if I have it working within the next 6 hours of work.
This is a fairly typical experience of using XCode for me. Many times getting codesigning working correctly and getting it working within the mac app store parameters takes more time than writing the code.
You can never, ever, just upgrade Xcode (or anything important, really) on a production Mac. Xcode, especially, needs to be installed on a sandbox machine first where it can destroy anything it wants. It's an effort, but still better than having production explode in your face.
That's probably a good approach. Still, when my certificates expire (which makes the provisioning profiles invalid), that alone will take hours or days to fix. So even if it's left in a completely untouched environment certificates expire after a year or two and I cannot recompile the project without a lot of work.
It's all using Apple endorsed formats. It's just using an awful lot of them. But it's all exactly how it's supposed to be. But because it's using a daemon, a Finder extension, command line interface apps, etc, they all have their own provisioning profiles and they all have to be codesigned in their own ways. Which is what makes it tricky.
They’ve been fixing this issue with every release of Xcode and it’s still broken. At some point we must realize that code-signing is something that the Xcode team will never be able to get working reliably due to incompetence or apathy (or both).
With automatic provisioning/specific profile mode, they definitely removed a lot of the sharp edges when it comes to provisioning, but they also removed all of the flexibility. It definitely feels like Xcode on training wheels with no option to remove them unless you rely on a now deprecated feature set.
And also not exactly good for creating (though arguably things could be made better for tablets with improved software and less idiocy like abstracting away the filesystem).
My iPad Prod is Fantastic for creation. It's a far better drawing/art tool unless I spend another $1k+ on a cintiq, it's a great video editor, really good music editor, and I even code on it a ton. It's without a doubt my favorite device. I have a surface pro 4, macbook pro, iphone 6 plus (soon a 7 plus), and my iPad Pro 12.9 in regular usage. I need all of them but for notes and art creation the iPad is the hardest to replace.
Interesting... you're one of the only people "in the wild" I have heard say this.
I've long been of the opinion based on what I've seen and personally found that mobile (including also most tablets) is basically worthless for anything but consumption and casual communication, with a comment or photo being the limit of their creative potential. If I want to really make something I want more I/O bandwidth and a "real OS" where my data can be mine.
Even less charitably I've seen the whole platform as one big dark pattern designed to turn users into passive consumers that can be transparently surveiled.
There are a bunch of others but those are my favorites/ones I've used in the past. I've been able to create full game prototypes all on my iPad. In fact the next game jam I do may just use my iPad. Pair it with a dropbox account and fast internet and I can handle almost anything a computer can, though admittedly it's limited in a lot of cases. Still can't do full releasable app builds on device for example.
I find mine fantastic for creating, it just depends what you want to create. A few days ago I got a programming assignment and wrote half of it in Pythonista on my phone on the train going home. I play roleplaying games and wrote up 95% of my current campaign notes, rules and reference sheets on my iPad. My daughter sketches on it with the pencil and uses it as a digitiser with the Mac. These things are fantastic creation devices.
Sure, some people don't like onscreen keyboards and such, but everybody has their preferences and comfort zones especially when it comes to creative activities. It's a very personal activity. But at this stage unequivocally saying mobile devices are not good for creating is just plain flat out provably false.
Tablets are not exclusive to Apple though. But in all seriousness I don't know anyone using a Microsoft Surface as a tablet except for maybe watching a movie.
Does this support VoiceOver and some sort of Sound API?
I occasionally teach blind kids programming. Sometimes it takes an hour to just navigate them through an unfamiliar setup with a screen reader. If this can be used by a blind person, it could be a game changer.
> [Jordyn Castor] was a driving force behind accessibility on Apple's soon-to-be released Swift Playgrounds, an intro-to-coding program geared toward children. She's been working to make the program accessible to blind children, who have been waiting a long time for the tool, she says.
I think it'd be really cool if it were included, but it'd take up a decent chunk of storage (App Store shows 268 MB), which would be a bummer for people on 16GB iPads.
I want a language + ide + (hosting/compiler) combo that's as easy to use as BASIC was back in the day. and scales all the way up from kids' apps to enterprise.
This looks so similar to Lightbot that I wonder if it's the same game just with updated graphics and characters and stuff.. and of course all the swift code
How are they going to make you buy shiny new iPads otherwise?
Edit: Why the downvote? I still have an iPad mini (1st gen), and I don't get to play with Swift Playground because iOS 10 requires iPad mini 2 or newer. Look, I'm as much an Apple fanboy as the next person: I use a MacBook Pro, I have an iPhone 6s Plus, and my wife will be getting an iPhone 7 Plus, but you can't deny that Apple, just like other companies, build arbitrary obsolescence into their products.
Even if you want to be cynical, the far more important strategic value in this is in developing more developers for their platform long-term. They wouldn't compromise that for the purpose of marginally more device sales.
That's a sensible argument. I can neither agree nor rebute until I get to play with Swift Playground. I can borrow my mom's shinier iPad Air when I see her. It'll all depend on how Swift Playground plays and feels. For example, there are some questions that will help me decide whether I'm being too cynical: will Swift Playground be only suitable for teaching kids or will it be good for advanced adult programmers coming from other programming languages as well? How much of Apple-specific API will it introduce, if at all?
I've been using Swift Playgrounds on my iPad Air since the second iOS10 beta. It's been really stable, plays well with my bluetooth keyboard and the error feedback on it is excellent. My wish list for the next version would include (a) the ability to create and edit files in *.playground/Sources and (b) a project navigator view to let me move assets around the folders inside a Playground or Playground Book on the device. That said, it's a great tool for education as well as prototyping.
iPad Mini 2 has 1 GB of RAM where the original had half as much. Typically Apple has only deprecated old iOS device models from new OS support due to hardware requirements.
If they allow an iOS version to be compatible with an under powered device that can barely run it they'll get criticized for slowing down older machines or even accused of deliberately crippling them down to force upgrades.
If they don't allow new iOS versions to run on older machines with lower specs, they get accused of deliberately deprecating older models to force upgrades.
Yeah. They wound up selling the iPad2/mini1 guts far longer than I would have thought smart. My iPad2 was feeling long in the tooth well before it stopped being sold new. (And I'm not the most demanding iOS user).
No, you're right, iPad mini 2 appears to be the hardware floor for Playgrounds - I can never keep the iPad SKUs straight. IIRC (and I may not, see above) that the 2 was the last 32 bit big shiny rectangle. But the point is there are multiple generations of existing devices that will run Swift Playgrounds.
Wow, this looks cool and very complete, the must have put quite some effort in this. I've been 'stuck' on Objective-C for a while now, knowing I should 'keep up' and learn Swift. This could be a nice, fun way to pick up Swift in my 'spare' time.
Not as exciting as AIDE I have 2 apps on Google play with over 20 thousand users both of them built in AIDE with a combination of Java and C++ right on my android device.
I hate iPad exclusivity. Like I get it, the content is better consumed on a bigger screen and you might be taking advantage of the better hw but maybe let me check it out and decide for myself if I'm willing to buy an iPad for the full experience.
They wanted to make an app for introducing kids to programming. There are already plenty of tutorials on the web, to run on a computer. A web-app or iPhone app would not have had a good enough UI and they probably don't have enough Android developers to make it work well on all Android devices.
Apple doesn't have unlimited people to assign to this project. They chose a platform where they can focus on providing the best experience for. Why complain?
There's really nothing stopping any of us from building a Swift Tutorial app on Android. I'm sure it's already been done, actually. But why would Apple want to do it?
