31–40 of 179 posts
Earlier quoted context omitted.
It will probably have a really short code signing certificate expiration date, so you'll have to rebuild and reinstall all the time. They'll probably notice when 100000 users debug-sign the same app ID too...
Re-signing could be done automatically when you plug your iDevice (unless TTL is really short like 1 hour). App ID, hash could be changed easily as well.
Earlier quoted context omitted.
Is that right? As of Mavericks, OS X by default refuses to run applications that are not signed with a 99$/year Apple certificate.
You can always right-click and select "Open".
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: missing bitcode is currently a warning for iOS, but it will become an error in an upcoming beta release of Xcode 7.) ENABLE_BITCODE should be consistently turned on for all the targets. If you use a library or framework provided by a third party, please contact the vendor for an updated version which contains bitcode."
Dear God, do we need to wait for all libs to update? :S
Earlier quoted context omitted.
> Program membership is not required. Though note that there's a current bug listed that looks like accounts with expired developer memberships currently can't use free provisioning. (For me, this is mildly irritating, because I let my membership lapse a few days ago on a hunch that they'd combine the developer programmes. And then they did, but I can't use the free provisioning, and the re-enrolment form doesn't see…
You can try to create a new Apple ID while they fixing the bug.
woops, repetition !
"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
That said, the spec here is a bit different than C++ exception I believe.
Earlier quoted context omitted.
You can always right-click and select "Open".
I can do that, but it's not reasonable to expect my users to do so. As it is, indie developers have to choose between paying rent to Apple and having most users unable to open their apps.
Plus, more than a few apps have added instructions on their download pages to show users how to get around Gatekeeper. They can clearly take the Gatekeeper hit, so you probably can too.
Earlier quoted context omitted.
Re-signing could be done automatically when you plug your iDevice (unless TTL is really short like 1 hour). App ID, hash could be changed easily as well.
If you change the app ID you start over with an empty app data directory, which is a bit of a hassle.
Earlier quoted context omitted.
I can do that, but it's not reasonable to expect my users to do so. As it is, indie developers have to choose between paying rent to Apple and having most users unable to open their apps.
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…
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 Windows for the endless sea of pointless dialogs its users had to go through. Those apps could take the shitty-UI hit, mine probably could too, but it still sucks. A lot of people are intimidated just looking at instructions like that, and will just give up.
I don't know about you, but I feel like that's a pretty terrible first-run experience for my app. I don't feel comfortable charging people for something they might not even be able to run. Would Apple be willing to put their own apps behind that kind of painwall?