"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
Some language designers feel it is so advanced that developers working on coal mines should not be allowed to use it.
What's new in Xcode 7
41–50 of 179 posts
Re: What's new in Xcode 7
#42"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
Not sure why this is downvoted. I find it totally appropriate to criticize marketing speak that is masked as technical description.
Regarding Apple, I find it inappropriate (and dishonest) to use the word "advanced", when it is just catching up with a commodity feature. Exceptions are provided by almost every other modern programming language in the world.
Re: What's new in Xcode 7
#43"Xcode 7 has a ENABLE_BITCODE option to embed bitcode in apps, app extensions, and frameworks. The option is turned on by default for iOS and is mandatory for watchOS projects submitted to the store. When bitcode is enabled for a target, all the objects, static libraries and user frameworks used when linking that target must contain bitcode. Otherwise, an error or a warning will be issued by the linker. (Note: missin…
Wow, that's quite a change! Is this some kind of intermediate LLVM language? Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet you can even change from ARM to x86 then!), but you're handing a lot of control and probably something much closer to the original source code over to Apple.
Is there a fundamental change of architecture planned for future iOS devices?
Re: What's new in Xcode 7
#44> Swift is a successor to both the C and Objective-C languages.
This says it all, regarding what the future for Objective-C looks like.
Re: What's new in Xcode 7
#45"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
Advanced != Exclusive/Innovative/... That said, the spec here is a bit different than C++ exception I believe.
Agreed. Also, it does look different aka innovative to me:
func loadData() throws { }
func test() {
do {
try loadData()
} catch {
print(error)
}
}
If so, their motto really seems to be 'explicit over implicit'. I'm not sure that is an improvement, but I'm not sure that it is bad, either, provided that the refactoring tools work fine (for example when one removes that "throws" from the definition of loadData)
Re: What's new in Xcode 7
#46"Xcode 7 has a ENABLE_BITCODE option to embed bitcode in apps, app extensions, and frameworks. The option is turned on by default for iOS and is mandatory for watchOS projects submitted to the store. When bitcode is enabled for a target, all the objects, static libraries and user frameworks used when linking that target must contain bitcode. Otherwise, an error or a warning will be issued by the linker. (Note: missin…
Wow, that's quite a change! Is this some kind of intermediate LLVM language? Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet you can even change from ARM to x86 then!), but you're handing a lot of control and probably something much closer to the original source code over to Apple. Is there a fundamental change of architecture planned for future iOS devices?
Along those lines, John S. just tweeted "ARM Macs…" [1], which is interesting, as he also got the Open Sourcing of Swift right a couple of days ago.
Re: What's new in Xcode 7
#47Earlier quoted context omitted.
Personally, that is a total game changer for me. I have an app idea, to build a custom house management app for my wife and I. I really don't care to put it on the app store and I don't want to pay $99 for a two person app. Now I can make an app that only my wife and I will use.
You can do this today. Just download XCode and go to town. Or use any other programming language supported on OSX like Python, Go, etc. etc.
This is the first time you could install apps on your device without paying for a membership. Previously you could design and test through a simulator for free, now he can build and actually use his app without paying extra as he isn't distributing.
Re: What's new in Xcode 7
#48"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
Not sure why this is downvoted. I find it totally appropriate to criticize marketing speak that is masked as technical description. Regarding Apple, I find it inappropriate (and dishonest) to use the word "advanced", when it is just catching up with a commodity feature. Exceptions are provided by almost every other modern programming language in the world.
exactly my point. It's marketing mumbo jumbo.
Re: What's new in Xcode 7
#49"Xcode 7 has a ENABLE_BITCODE option to embed bitcode in apps, app extensions, and frameworks. The option is turned on by default for iOS and is mandatory for watchOS projects submitted to the store. When bitcode is enabled for a target, all the objects, static libraries and user frameworks used when linking that target must contain bitcode. Otherwise, an error or a warning will be issued by the linker. (Note: missin…
Wow, that's quite a change! Is this some kind of intermediate LLVM language? Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet you can even change from ARM to x86 then!), but you're handing a lot of control and probably something much closer to the original source code over to Apple. Is there a fundamental change of architecture planned for future iOS devices?
http://llvm.org/docs/BitCodeFormat.html. Way closer to assembly than Java/.NET byte codes. Also potentially processor specific.
My guess is that it is future-proofing towards running iOS apps on Mac OS and/or running (parts of) iOS apps on the Apple Watch. It also might mean that Apple plans to make their own ARM extensions (for example, I suspect having the CPU know about tagged pointers, so that an 'add' instruction can do an indirection, if needed, might be an overall win)
Update: the release notes for the Xcode 7 Beta say:
"• Bitcode. Archive for upload to the App Store in an intermediate LLVM binary representation that the store can then optimize into the 64 or 32-bit executable to be delivered to customers."
This falls under a feature they call 'App Thinning'. It makes the App Store optimize an app for the device it gets installed on, CPU-wise and asset-wise, and also allows your app to download some resources on demand.
Re: What's new in Xcode 7
#50Earlier quoted context omitted.
I mean, really, you're comparing paying rent with a $100/yr fee (which now allows you to sign apps across their platforms)? Really? I highly doubt most indie developers even have to make that choice. Finding the $100 a year is not the most impossible task in the world, even for a tiny indie developer. Plus, more than a few apps have added instructions on their download pages to show users how to get around Gatekeeper…
I could afford $100 a month. Affordability is not the point. The point is that Apple will block your app from opening by default unless you pay them a recurring fee, and if not, you must incur additional support burden to teach users how to get around the problem. Yes, lots of apps do post instructions on how to get around it, but lots of apps do all sorts of user-unfriendly things. We Apple users used to make fun of…
> I don't feel comfortable charging people for something they might not even be able to run.
Honestly, if you're charging users, then there's absolutely no question about it, you get the membership. Your entire "expecting the user to do so" point completely goes out the window the second you said it's a paid app. If you have the revenue, then it's simply a cost of doing business in the Apple world. Plus, once again, you're being way overdramatic. "might not even be able to run" is taking it a bit too far. Your app will be able to run. If you don't trust your users enough to click twice, then maybe you need to learn to trust them more. It's not like it's a hard thing to do, and it only needs to happen once.
Remember, this is Apple's OS, Apple's ecosystem, and Apple's SDKs. You play by their rules or not at all. That's the way it's always been, and that's the way it will probably always be (but never say never, look at Microsoft, they're doing things nobody would have ever expected). Yes, it sucks. Yes, it isn't fair. But as with all major companies, it never is. They will always have the upper hand because they're the ones providing the user base and all the tools necessary to get the apps out there and onto their machines. As long as you are developing for their platform, you have to play by their rules. Honestly, be happy they haven't moved the default to the much more restrictive "Mac App Store" yet.
And to be fair, I see where Apple (and Microsoft, IIRC they have SmartScreen which does the same sort of thing but to a lesser extent) are coming from. I'm sure that it lowers the chance of accidentally executing viruses by quite a bit and also slowly is teaching users to think before they execute (especially if you have to right click and click Open).