Live data from Hacker News

What's new in Xcode 7

developer.apple.com

51–60 of 179 posts

Re: What's new in Xcode 7

#51
post #43

Earlier quoted context omitted.

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. [1] https://twitter.com/siracusa/status/608029277963972608

Interesting, although the open sourcing of swift feels more obvious than arm macs. Bitcode and app thinning are currently ios+watchos only. I think it sounds more likely for ios and especially the watch changing architectures in the future rather than a non-x86/64 osx. But I'm probably wrong.

What would be the selling points for an ARM MAC? Access to the iOS app store software library? (unlikely) Better battery usage? (maybe) Super cheap devices? (un-apple-like)

Changing archs has been done before but I don't see a rosetta for intel apps running smoothly on arm. Virtualizing windows and linux is another killer app for intel macs that would be missed for some.

Re: What's new in Xcode 7

#52
post #40

Earlier 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…

> A lot of people are intimidated just looking at instructions like that, and will just give up.

You realize it's probably one of the easiest tasks ever, and it's literally 3 steps. Anybody even my grandma can do that. If they know how to download your app and "install it" they will be able to do those simple steps.

And it's a one time thing, not like they need to do it every time they go to install an app.

Re: What's new in Xcode 7

#53
post #49
post #43

Earlier quoted context omitted.

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' instructi…

Oh ok. So would you need two sets of bitcodes to target ios32 and ios64? A lot of fundamental types like CGFloat have different sizes...

Re: What's new in Xcode 7

#54
post #34

"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…

Agreed, this is an insane requirement. Our app uses commercial libraries from closed source vendors, some of which are no longer distributing newer versions of their libraries. If this becomes a requirement, we will not be able to ship our app because we can't deliver the entire thing in bitcode.

Re: What's new in Xcode 7

#55
post #40

Earlier quoted context omitted.

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…

> A lot of people are intimidated just looking at instructions like that, and will just give up. You realize it's probably one of the easiest tasks ever, and it's literally 3 steps. Anybody even my grandma can do that. If they know how to download your app and "install it" they will be able to do those simple steps. And it's a one time thing, not like they need to do it every time they go to install an app.

Anybody can do it if they're of the right state of mind, but as somebody who used to do IT for a medium-sized office, all I can say is you're mistaken if you think most people are that way. The task is intimidating and involves 1) going through a context menu (something many Mac users will never even have done before), 2) dealing with a dialog (people get nervous the second a dialog shows up and often don't even read them), 3) if they have read the dialog, ignoring the fact that they're doing something it's telling them not to do.

Re: What's new in Xcode 7

#57
post #12
post #2

Unexpected: "Xcode 7 and Swift now make it easier for everyone to build apps and run them directly on their Apple devices. Simply sign in with your Apple ID, and turn your idea into an app that you can touch on your iPad, iPhone, or Apple Watch. Download Xcode 7 beta and try it yourself today. Program membership is not required."

I love this. I'm thrifty and haven't paid for a dev account but am deep into an app build. When I show clients, there's a bit of an awkward conversation when I explain that I have to show them on my macbook. If I could demo directly on my phone/tablet that would be amazing. Can't wait to use this feature!

you misspelled cheap

Re: What's new in Xcode 7

#58
Not even a mention of refactoring tools for Swift? Right now you can't even do a Rename. This was one of the biggest reasons I bought Appcode, actually. And I'm still waiting for either IDE to implement Extract Method.

It boggles my mind how little I hear people complain about this. Aren't these basic tools by now?

Re: What's new in Xcode 7

#59
post #55

Earlier quoted context omitted.

> A lot of people are intimidated just looking at instructions like that, and will just give up. You realize it's probably one of the easiest tasks ever, and it's literally 3 steps. Anybody even my grandma can do that. If they know how to download your app and "install it" they will be able to do those simple steps. And it's a one time thing, not like they need to do it every time they go to install an app.

Anybody can do it if they're of the right state of mind, but as somebody who used to do IT for a medium-sized office, all I can say is you're mistaken if you think most people are that way. The task is intimidating and involves 1) going through a context menu (something many Mac users will never even have done before), 2) dealing with a dialog (people get nervous the second a dialog shows up and often don't even read…

> (something many Mac users will never even have done before)

This isn't the 90s. Two-button mice are the default now, and have been for many years. I'm pretty sure everybody has done it at least once, and probably even knows what the term "right-click" means.

> ignoring the fact that they're doing something it's telling them not to do.

They're not doing something it's telling them not to do. Have you even looked at the dialog? Have you read it yourself? It simply asks the user if they're sure they want to open it as it's from an unidentified developer: https://support.apple.com/library/content/dam/edam/applecare... Nothing in it is telling them they shouldn't or can't open the app, they're not going against anything by saying "Open" (in fact, that might just be why there's an Open button there in the first place, because it's an acceptable choice).

Seriously, you're being overly untrustworthy about your users here. You seriously can't think this is that big of a problem. Because it isn't. Other apps have managed to solve this with download instructions, it's really not difficult, and the fact that they're still alive and running shows that users clearly know what they're doing enough to right click once and press Open once. It's not a difficult task by any means of the imagination.

Re: What's new in Xcode 7

#60
post #40

Earlier quoted context omitted.

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,…

> 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.

Yes, because Apple demands rent. They create a problem and then charge you to fix it. This is called rent-seeking. I think that is a bad behavior.

> 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.

I used to do tech support for a medium-sized office. I would frequently get called to people's desks because their computer wasn't working, only to find that their email client had put up a dialog with the message "The email address 'somebody@thatcompany.cok' is not a valid address", I'd have to verbally tell them they mistyped the address — sometimes, even after this, they'd just stare at me like a deer in the headlights and I'd have to type in ".com" for them before they felt like they could use their computer again. And then they'd do it again the next day.

I remember patio11 once shared an anecdote about a school teacher who called his support number because she thought Bingo Card Creator had broken Google. It turned out that she'd gotten a new home computer and Bing was the default search provider, and she couldn't figure out how to operate Bing because it wasn't Google.

I have to wonder if you have had to do a lot of support work, because I think you're trusting users way too much. There are many, many people who are really not stupid, but get flustered when doing unfamiliar tasks on a computer.

> 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

No, it isn't. It wasn't even this way just five years ago. I was one of the early adopters of OS X, and one of the things I loved about it was how open it was, so even some kid like me (at the time) could easily make software. Apple has gotten worse and worse about this over the past decade.

Post reply on HN