Apple Releases Swift Playgrounds 4 (techcrunch.com) 8
Apple announced that it has officially released Swift Playgrounds 4. The tech giant first announced the upcoming launch of the new software at WWDC earlier this year. From a report: With this latest launch, the software now lets users build iPhone and iPad apps with SwiftUI directly on their iPad. It also allows you to preview apps in real time as you make changes to your app. Apple notes that developers are now able to upload their finished app to the App Store with its "App Store Connect" integration. "Swift Playgrounds is the best and easiest way to learn how to code," Apple said in a blog post. "Code is immediately reflected in the live preview as you build apps, and you can run your apps full screen to test them out. A new open project format based on Swift packages can be opened and edited in Swift Playgrounds for iPad, as well as within Xcode on Mac, offering you even more versatility to develop apps across iPad and Mac."
Wonder how slow this will be (Score:2)
I should probably actually try this thing about before commenting on it, but I've just recently been making an iOS app using SwiftUI in Xcode, and I have to say, given how absolutely lousy an experience that has been with a MacBook Pro, I can't imagine how lousy an experience doing the same thing on an iPad would be.
In Xcode, the previews would just randomly "pause" for no apparent reason. They were slow to update and it wasn't always clear if the preview you were seeing was the current code or the last suc
Re: (Score:2)
I'd imagine not much of xcode is present in swift playgrounds, why would they want to stuff the whole IDE into your phone or tablet?
Really? (Score:3)
"Plus, if the source code got "too complicated" (and from what I can tell that really meant "more than 100 or so lines") the entire thing would break down entirely and Xcode would refuse to compile it at all."
Working in XCode back to 2010-ish (I became a "certified" iOS developer!). I never ONCE saw that.
Re: (Score:3)
With SwiftUI and Swift specifically, yes.
It has something to do with type checking in the "domain specific language" that SwiftUI implements on top of Swift. If the file gets too long, for whatever reason, the type checking becomes "too complicated" or it can't deduce types or something, and it makes the Swift compiler explode and just give up.
Note that this is a problem specific to SwiftUI and Swift. Since Swift wasn't released until 2014, if you were using Xcode around 2010, you weren't using Swift in Xco
Re: (Score:2)
Was using XCode "since" 2010-ish. :)
But yes, my experience in SwiftUI is very limited. That seems like a pretty big compiler behaviour problem to exist at all.
Re:Really? (Score:4, Interesting)
I'm not sure how much it's a compiler problem and how much it's just a Swift problem or a SwiftUI problem.
Under the hood SwiftUI turns out to be a giant mess of generic Swift structs modified with extensions. (Generic in this case meaning type generics, think Foo<Bar>.) So some of the typing is simple: Text("Foo") is a Text struct. However, some things aren't: Text("foo").textCase(.uppercase) does not return a Text. It returns "some View". (Also, for those who know Swift, note that they're structs, not classes. This means that they don't extend View, they implement the View protocol.)
All this means that while you might think Text("Foo").font(.system(size: 32)) would just modify the existing Text to use a different font, it instead returns an entirely new instance of an unspecified struct that implements the View protocol. (After all, structs are all pass-by-value, so the return value from font(_:) is a new value.)
This makes trying to resolve the issues incredibly annoying, as you can't easily tell Swift what the "real" types are and resolve its type-resolving, because they turn out to be weird internal SwiftUI generic types. The "real" solution is to split your UI into smaller components. It's just that they may be smaller components than you'd have expected.
So anyway. Now imagine trying to deal with all that on an iPad.
Shouldn't be slow. (Score:1)
SwiftUI on Xcode has to work through a simulator instance, so it's a bit of a hack. Although I've not tried it yet either, on an iPad SwiftUI should basically be native speed with just a bit of compilation overhead - but recent year iPads were about as powerful as laptops so that should be OK.
Xcode and Storyboards I find more straightforward, but I can see if you aren't used to them and hadn't tried to build up anything complex SwiftUI would seem simpler. However I've been working with SwiftUI and things
+1 insightful? (Score:2)
> I should probably actually try this thing about before commenting on it,
I am not sure, but in a way this is an insightful comment.
(Dang, there went my mod points!)