Xcode 8(developer.apple.com)

44 pointsby apogosyanvor 10 Jahren13 comments

developer.apple.com

https://developer.apple.com/xcode/

13 comments

"Developing and running your app on your Apple device is as easy as entering your Apple ID into Xcode preferences. Apple Developer Program membership is not required."

Is this a recent change? Sounds like a boon to indie devs.

DerekLvor 10 Jahren

It started last year with Xcode 7.

blindelephantsvor 10 Jahren

I just started using this. Maybe someone else can confirm whether this is true for paid accounts as well... with unpaid accounts, you're limited to 10 program builds per week. As in, 10 separate programs built and loaded onto a device.

I don't know the fine details, just ran into that wall last week as I was loading a bunch of different tests and examples to an iPad.

flohofwoevor 10 Jahren

There is one extremely annoying change regarding provisioning for iOS: you now need to manually set a 'development team' for each single app target, and there is no default. You'll have to set one. This is annoying for projects with many app targets (I have projects with 10..20 app targets). There's no way you can distribute source code (either with Xcode project files or cmake build files) which just compile and run out of the box. You first need to go into into the settings and set the development team for every single target. And if you recreate the Xcode project files with cmake you need to do it again. How this should work with automated builds and continuous integration servers is beyond me.

mmargerumvor 10 Jahren

That sucks. We have one target for the store and one target that uses our enterprise provision we use for internal testing. I suppose we can just use test flight now.

oriendvor 10 Jahren

What is an app target?

x13vor 10 Jahren

"The deployment target setting specifies the lowest operating system version that your app can run on. For example, the lowest available setting for iPad apps is iOS 4.3."

from

https://developer.apple.com/library/content/documentation/ID...

chillacyvor 10 Jahren

> The new automatically managed code signing generates all the assets you need to properly sign, provision, and run your apps on a connected Apple device. Simply choose your team and Xcode does the rest

I really hope so, that's easily the most annoying part of the app development experience. The fact that I have workflows and code from 2012, predating both swift and ARC only makes this worse

elsurudovor 10 Jahren

They've made this promise before, and it's already supposed to be working (iOS Team Certificates, etc.). So whether they got it right this time and it actually works... we'll see

0x0vor 10 Jahren

I've had so much trouble with xcode automatically adding "xcode managed profile: *" a million times in the developer portal, even despite me having configured an app-id-specific profile (for custom provisioning profile settings such as push notification certificates), and then having it pick the wrong team and/or provisioning profile causing push messages to break, so I've stopped logging in to xcode completely. It's not so bad managing provisioning profiles in the dev portal when you get the hang of it. Unfortunately xcode removed most of the GUI for managing installed profiles, but the fastlane tools (including "sigh manage") help a bit.

kskvor 10 Jahren

Do they still force you to upgrade the entire OS just to use an IDE?

bumblebritches5vor 10 Jahren

Nope. Xcode 8 is supported on El Cap and Sierra. not sure about Yosemite.

epynonymousvor 10 Jahren

just fyi, swift 3 is now supported in xcode 8, there are quite a few changes that i've noticed when trying to convert:

1. you probably shouldn't convert to swift 3 yet, x8 allows you to use swift 2.3 which is safe for now, deprecated later meaning later releases of xcode (8.1, 8.1.1, 8.2, 8.3, 9.0?) 2. if you have unchecked-in git changes, make sure you commit/push before "converting" as converting will make all sorts of changes to your code including cocoapod dependencies like Alamofire, etc. i did a 'pod update' to see if that would help, to see if dependencies like Alamofire converted their code to swift3, but doesn't seem like it from a cursory glance. i think that responsibility should be on the pod owners, not for you to do in your workspace. 3. once you convert to swift 3 the only way to get back to a swift 2.3 is to rm the entire project, clone from a remote git repo. at least that's if you're not already swift 3 compatible.