|
Honestly, NSNull vs nil is just people trying to work around earlier bad decisions, and I look forward to the day that it's forgotten trivia (Did you know that NeXTStep made a singleton object to represent the absence of a value because they made their other representation of the absence of a value mean something else in their standard collection types?)
|
# ? May 21, 2015 06:23 |
|
|
# ? Jun 6, 2024 06:13 |
|
So that code injection blocker I posted a while back apparently breaks UIActivityViewController (and probably other things) Found this out after the update using it was live . I'd set the build settings to only use the injection blocker for the distribution build (as per the blog post), and this is what I deserve for testing Release but not Distribution. My quick bug fix update wound up completely breaking the share sheet. Not really sure what to make of iOS itself doing code injection. Especially since code injection is one of the major ways to steal IAP and so being able to block it is a big plus.
|
# ? May 21, 2015 06:44 |
|
Doctor w-rw-rw- posted:I'd sum it up as: If you want nil semantics then use nil. If your collection doesn't support nil then don't violate its assumptions. It's otherwise just a sentinel object, not some special class of object that isn't like other objects. Not being different means it's simpler to reason about. My issue is with the @{} notation and auto boxing numerical why won't it box a nil.
|
# ? May 21, 2015 15:22 |
|
Also @{} and @[] auto-indentation
|
# ? May 21, 2015 20:11 |
|
Switched over my personal iOS developer account to a corporate account today. I'd been putting it off for a while because I expected it to be some tedious, drawn out process that involved faxing paperwork in 2015, but the whole thing took less than an hour.
|
# ? May 22, 2015 05:01 |
|
I'm chasing a nasty memory corruption bug that causes crashes that are very hard to reproduce. Maybe you can help me go about it in a smarter way than testing about two dozen different builds, each at a different revision (why didn't I catch this earlier? because it only seems to happen in optimized builds running outside the debugger), hoping one will crash reliably It's not random corruption. What happens is that the isa pointer in a random object gets overwritten with a small integer, sometimes zero, but can be 9, 11... It's not reuse of dead objects, I tried zombie objects already (very rarely, it does crash under the debugger). It's not buffer overflow apparently, I tried guard malloc (I could probably try harder, but Xcode likes to crash when launching the app in the simulator). It doesn't seem to be freeing the wrong object, because I tried enabling scribble. Any ideas?
|
# ? May 22, 2015 08:35 |
|
hackbunny posted:I'm chasing a nasty memory corruption bug that causes crashes that are very hard to reproduce. Maybe you can help me go about it in a smarter way than testing about two dozen different builds, each at a different revision (why didn't I catch this earlier? because it only seems to happen in optimized builds running outside the debugger), hoping one will crash reliably Two dozen builds? Would bisecting to test help? Might help you go from testing 24 builds to – hopefully – 5 (aka ceil(log2(24)).
|
# ? May 22, 2015 08:47 |
|
Doctor w-rw-rw- posted:Two dozen builds? Would bisecting to test help? Might help you go from testing 24 builds to – hopefully – 5 (aka ceil(log2(24)). I wasn't really thinking straight yesterday. I reviewed all revisions, rated their "shiftiness" from 0 (harmless) to 5 ("wtf did I write"), and tried them one by one, starting from the shiftiest. Some background: the revisions were all fixes suggested by a code analysis tool, and a lot of them related to manual (malloc/free) memory management, so I thought I could make things quicker by testing those first. Today I tried bisection (and I installed IPAs manually instead of going through Testflight, I had to be really tired) and it turns out the most likely offending revision I had rated "2" e: and it's more than 5 builds, I can't assume there's only one bad revision. Still much quicker hackbunny fucked around with this message at 12:30 on May 22, 2015 |
# ? May 22, 2015 12:26 |
|
Objective-C code:
(please don't mention ARC. Just... don't) e: guard malloc does, did catch it I mistook the out of bounds write for a memory corruption bug for some goddamn reason. I don't know how I could be so stupid hackbunny fucked around with this message at 15:16 on May 22, 2015 |
# ? May 22, 2015 13:21 |
|
Hate to spam the thread, but what is this poo poo?quote:Xcode quit unexpectedly while using the AppName plug-in. It keeps happening when I try to debug the application in the simulator. The application runs fine, the simulator is just peachy, but Xcode keeps crashing e: quote:Failed to lookup the process ID of AppName after successful launch. Perhaps it crashed after launch. NO, gently caress YOU XCODE, THE PROCESS DIDN'T loving CRASH YOU GIBBERING IDIOT hackbunny fucked around with this message at 14:26 on May 22, 2015 |
# ? May 22, 2015 14:17 |
|
hackbunny posted:Hate to spam the thread, but what is this poo poo? Xcode's code signature is breaking due to touching your incorrectly signed code - see if you can resign your app and/or analyze it with codesign to see what's wrong. Xcode crashes because it's entitled to do things and with that comes the bit that says 'kill me if I touch wrongly signed code'. Xcode is supposed to be more careful when it debugs another app in order to not get its code signature screwed up, feel free to file a bug: https://bugreport.apple.com
|
# ? May 22, 2015 17:53 |
|
chimz posted:Xcode's code signature is breaking due to touching your incorrectly signed code Why are Simulator builds even signed? and why building the same identical code twice in a row can produce a good build followed by a broken build? I seriously can't count the time I've wasted on inexplicable "executable was signed with the wrong entitlements" errors. Sometimes a clean and rebuild fixes the issue, sometimes it doesn't. Sometimes refreshing my account's list of provisioning profiles works, sometimes it doesn't. Things have slowly improved in the couple years I've been using Xcode, but the issue never went away Oh and Testflight will happily distribute badly signed/provisioned executables chimz posted:see if you can resign your app How is this done? Is there any documentation on code signing, a specification maybe? I've never used codesign, I probably should start. Will it catch issues with bad provisioning profiles too? chimz posted:Xcode is supposed to be more careful when it debugs another app in order to not get its code signature screwed up, feel free to file a bug: https://bugreport.apple.com If anyone reads crash reports, I posted like six or seven in a row yesterday. The increasing amount of f-bombs in the comments field is directly proportional to my frustration I'll try to file a bug on Monday anyway Thanks
|
# ? May 22, 2015 18:42 |
|
I wanted to use HealthKit.https://developer.apple.com/library/ios/documentation/HealthKit/Reference/HealthKit_Framework/ posted:the framework constrains the types of data and units to a predefined list. These limits ensure that other apps understand both what the data means and how it can be used. As a result, developers cannot create custom data types or units.
|
# ? May 23, 2015 12:03 |
|
alanthecat posted:I wanted to use HealthKit. I don't see that as an entry in the Health app, so I don't think so.
|
# ? May 23, 2015 13:57 |
|
carry on then posted:I don't see that as an entry in the Health app, so I don't think so. Yeah, I saw it's not there, but is the current list any bigger than the list on launch day? I.e. are Apple actively (!) adding new types and I can hold out hope it will be there soon?!
|
# ? May 23, 2015 14:27 |
|
Is iTMSTransporter + a script like the one at the bottom of this tutorial still the best way to upload 200+ localized screenshots to iTunes Connect?
|
# ? May 25, 2015 22:10 |
|
lord funk posted:Is iTMSTransporter + a script like the one at the bottom of this tutorial still the best way to upload 200+ localized screenshots to iTunes Connect? http://fastlane.tools/ That is all. These things work pretty great. Take screenshots, push builds, update metadata, all without having to log in to iTC.
|
# ? May 25, 2015 22:22 |
|
Inevitable Ross posted:http://fastlane.tools/ Sure could've used this 2 weeks ago. 22 languages x 5 screen sizes x 5 shots x 2 app skus means a lot of time spent in iTC
|
# ? May 26, 2015 00:37 |
|
Thanks for the fastlane tip, but I ended up just doing the iTMSTransporter stuff since I didn't really need screenshot automation, just a better way to upload instead of the web interface. Feels sooooo good not to be dragging images into the web view.
|
# ? May 27, 2015 14:30 |
|
That's fair. FWIW - and late, sadly - `deliver --skip-deploy` will push a folder of screenshots up to iTC if they're in the right place. The documentation could use some help, but they seem like pretty useful tools.
|
# ? May 27, 2015 17:35 |
|
Weird. Got notification from UPS that my Watch is being delivered tomorrow. I got that notification BEFORE getting the email from Apple saying it had been shipped. Shipped so fast it went BACK IN TIME! Anxious to mess around with it, though.
|
# ? May 27, 2015 19:59 |
|
It's not ready for prime time imo I've had mine for ~2-3 weeks and I find myself using it less and less. I'm willing to bet it'll be better once we can actually run things on the watch but I bet it slays the battery.
|
# ? May 28, 2015 03:50 |
|
I'm starting to see folks who have the watch just using their phone more and more.
|
# ? May 28, 2015 15:50 |
|
The irrational desire to fill those three circles is the only "killer app" I need.
|
# ? May 28, 2015 16:47 |
|
Citymapper is pretty baller for getting bus times on your wrist but the scattershot speed at which it (doesn't) launch and fetch data kills it
|
# ? May 28, 2015 17:11 |
|
So when you finally are ready to submit your app and you switch to the 'live' server for in-app purchasing, and you run the app one more time, trying to purchase something should just flat out fail, right? No login prompt, just failure. Right? This is all just slightly unnerving.
|
# ? May 30, 2015 20:58 |
|
extern NSString const *kSomeConst extern NSString *const kSomeConst extern *const NSString kSomeConst extern const NSString *kSomeConst Is there any difference between these other than syntax? I keep seeing different styles in different projects and I want to know if there's any well defined best practice or whatever
|
# ? May 30, 2015 21:19 |
|
Hopefully you're not seeing all these different ones because there's only one that makes sense in Objective-C A good trick is to read from right-to-left:status posted:extern NSString const *kSomeConst status posted:extern NSString *const kSomeConst status posted:extern *const NSString kSomeConst status posted:extern const NSString *kSomeConst
|
# ? May 30, 2015 21:42 |
|
Flobbster posted:Hopefully you're not seeing all these different ones because there's only one that makes sense in Objective-C In various projects I've seen mostly the 1st and 2nd options. I just mixed things around a bit for the last two examples (hence 3 not compiling, lol). Thanks for the clarification.
|
# ? May 30, 2015 21:52 |
|
lord funk posted:So when you finally are ready to submit your app and you switch to the 'live' server for in-app purchasing, and you run the app one more time, trying to purchase something should just flat out fail, right? No login prompt, just failure. Right? It depends. What error are you getting back? You should only use the live server for the actual binary downloaded from and signed by the App Store, because if it hasn't been signed by the App Store then the purchases made by StoreKit will be made in the IAP testing sandbox. Trying to verify against the live verification server will always fail on purchases made in the sandbox. If you're doing server-side verification, have the app tell your server whether it's a build distributed through the App Store or not, and have the server choose whether to check the live server or the sandbox server based on that. You shouldn't have to "switch" between the two, because then it won't work when you're testing the next version of your app. The purchases will be made in the sandbox (since the new version wasn't signed by the App Store), yet to keep the shipping version of your app's IAP working your server will still have to check Apple's live server. And if you're trying to do verification on the device by checking the verification servers from within the app: don't. Anyone trying to steal your IAP will almost certainly be running a jailbroken device and be using something that redirects traffic meant for the Apple verification servers to a phony verification server.
|
# ? May 31, 2015 00:04 |
|
I might have no idea what I'm talking about but I wonder whether foiling the subset of jailbroken users who would rather put their time into defeating your copy protection than give you a dollar is worth the bother.
|
# ? May 31, 2015 01:36 |
|
You don't need to do anything, there are automated tools. You don't even have to crack the app, they do it by attaching to your app's process and intercepting calls to StoreKit, and they almost certainly modify the hosts file to aim the IAP verification servers somewhere else. And Lord Funk's app was $30 last time I checked, so I image his IAP is gonna be more than $0.99.
|
# ? May 31, 2015 02:12 |
|
Confirmed, I have no idea what I'm talking about.
|
# ? May 31, 2015 03:01 |
|
Stealing IAP is indeed ridiculously easy for jailbroken users. Once the tweak is installed, all the user has to do is click buy and hit cancel on the iCloud password prompt. No effort at all.
|
# ? May 31, 2015 05:09 |
|
Doc Block posted:You should only use the live server for the actual binary downloaded from and signed by the App Store, because if it hasn't been signed by the App Store then the purchases made by StoreKit will be made in the IAP testing sandbox. Trying to verify against the live verification server will always fail on purchases made in the sandbox. This is what I figured, just paranoid so I tried it anyway. Yeah my IAP totals $7 for all the patches and tuning functionality. Frankly I'm not terribly concerned about pirating, even if it does happen. I do agree with fleshweasel that you can spend too much time focusing on people who wouldn't pay for your stuff anyway.
|
# ? May 31, 2015 12:57 |
|
Doc Block posted:If you're doing server-side verification, have the app tell your server whether it's a build distributed through the App Store or not, and have the server choose whether to check the live server or the sandbox server based on that. I thought the recommendation was to always hit live and if it returns the code for "its a sandbox receipt" then try again against sandbox. (The whole never trust the client thing?)
|
# ? May 31, 2015 16:05 |
|
Hughlander posted:I thought the recommendation was to always hit live and if it returns the code for "its a sandbox receipt" then try again against sandbox. (The whole never trust the client thing?) I thought that was only for subscriptions? Like, it won't tell you that for any other receipts? Also, you should definitely be communicating with your own server over SSL + SSL certificate pinning.
|
# ? May 31, 2015 18:13 |
|
Doc Block posted:I thought that was only for subscriptions? Like, it won't tell you that for any other receipts? No, it will for others that's how we do our main IAP flow. Will check on the value.
|
# ? Jun 1, 2015 14:50 |
|
Who's in town for WWDC?
|
# ? Jun 7, 2015 21:22 |
|
|
# ? Jun 6, 2024 06:13 |
|
Well I live here now but I'm also going to WWDC.
|
# ? Jun 7, 2015 22:00 |