|
kuroshi posted:He still intends to support iOS 6.1. For personal reasons. He is in charge of the project, after all. The business reason is that he actually happens to own several devices that were EOLed at iOS 6.1, and by gum, he'll make sure his software runs perfectly on them as well as any new device. Juul-Whip fucked around with this message at 20:16 on Jan 8, 2016 |
#
?
Jan 8, 2016 20:13
|
|
|
|
| # ? May 16, 2024 18:47 |
|
|
kuroshi posted:So far, it's interesting benchmarking things on my various devices, since I have to limit various quad core Android devices to only two benchmark threads to compare per-core performance to the iOS devices I have, since they're all dual core devices. So far, the iOS devices stomp all over everything else.  I was astounded by how slow my DragonBoard 410c is despite having a quad-core arm64 CPU, even in comparison to my Raspberry Pi 2. The two score about the same on a single run of byte-unixbench, and the DragonBoard actually scores worse for four parallel runs: 340 versus 420 for the RPi2 which isn't even running armv7-optimized code! Alas, there won't be directly-comparable numbers for iOS, tvOS, etc. any time soon since the benchmarks are all separate binaries driven from a Perl script and they also do things like measure fork and pipe overhead which iOS apps can't do. (Plus even if I could run them, I couldn't share.)
|
|
#
?
Jan 9, 2016 02:07
|
|
|
Has anyone run into trouble getting Xcode/sourcekit to provide autocomplete in unit test targets? For some reason our framework's unit tests give no autocompletion and all types that come from the framework show up as <<error type>>. The main app's unit tests used to have this problem and it turned out to be a module reference problem (the main app was using module A which imported module B; adding an explicit reference so both the app and unit tests directly referenced B solved the problem). No such luck with the framework project; adding explicit references to all dependencies to both the framework and its unit tests didn't help. I re-tested everything by doing stuff one step at a time, nuking DerivedData, building, building for testing, then making sure the Indexing process completed. I see some tracing/debugging stuff in the sourcekitd code but I have no idea how to get Xcode to pass those flags along, nor is there any log output or console output that I can see. Oh did I mention that both projects and their unit tests compile just fine and all tests run & pass? Yeah. Apparently Xcode/sourcekit have a separate interpretation of valid code than the actual compiler.
|
|
#
?
Jan 13, 2016 19:23
|
|
|
Ugh. Sporadic KERN_INVALID_ADDRESS in a C library, only happens when profiling. What a pain in the rear end. edit: oh boy oh boy I think there's a library update: quote:0.8.1: 2015 Jun no they just linked it to the github repo okay all is well. lord funk fucked around with this message at 17:54 on Jan 14, 2016 |
|
#
?
Jan 14, 2016 17:29
|
|
|
I'm trying to autoplay an HTML <video> inline within a UIWebView. From what I've read I should be able to do this, but it's not working (there's no autoplay). I'm setting code:HTML code:Please point out the dumb thing I'm not doing.
|
|
#
?
Jan 14, 2016 22:39
|
|
|
Currently doing some stupid debugger tricks. I want to log the time a breakpoint was hit, but also the hit count. so I'd like to see "at 2:33: hit 5". I know I can execute NSLog(), and I can also just print a message with the hit count, but I don't know how to combine the two. I can't use %H in an expression. Is there a simple way to do this, or do I just have to log the hit count and then call NSLog with some placeholder to get the timestamp? e: Hm, if I break into the debugger from where my breakpoint is, I get EXC_BAD_ACCESS on NSLog, but if I do it earlier in the app, it works fine. Not sure what's up with that. Guess I'll have to live with no timestamps. Dessert Rose fucked around with this message at 22:20 on Jan 18, 2016 |
|
#
?
Jan 18, 2016 22:00
|
|
|
So I'm nearning the end of the beta testing phase and we're gonna release soon. How big a hurdle is the final release app review? I've never been rejected for TestFlight but I'd imagine the bar is higher. Anyone willing to share if they've been rejected and what the reasons were? Was it pretty easy to sort out?
|
|
#
?
Jan 21, 2016 20:01
|
|
|
I've had two rejections. One was because apparently the app reviewer was blind and claimed the app didn't work on iPad. Their reasoning was that they couldn't find the button to take a photo when running on iPad, despite it being in the same place as it is when running on iPhone. Luckily the appeal board agreed with me, the rejection was overturned within a day or two, and I didn't have to resubmit. The other time was for a game. The game had initially been accepted just fine, with a rating of 12+ for frequent cartoon violence, but an update was rejected for having an inaccurate rating. The reviewer claimed the game has to be rated 17+ because of Frequent Realistic Violence, because the main character carries a gun. I asked for clarification and the answer was basically "Gun = Realistic Violence", and since said "realistic" violence is pretty frequent that means a 17+ rating. The main character, by the way, is a cartoon dog, and the gun is really more of a badly-drawn gun-like object that shoots laser blasts at robots. Super realistic  In the later case I just changed the rating and resubmitted because I didn't want future updates getting held up over whether or not cartoon guns should be an automatic 17+ rating.
|
|
#
?
Jan 21, 2016 20:22
|
|
|
Ooooh boy. Rejected... ...because there was no way to restore purchases, because the reviewer couldn't be arsed to scroll to the bottom of the purchases and find the 'Restore Purchases' button. ...because the update copied documents into the user's Documents folder, even though it had been doing that for 1.5 years. ...because the reviewer didn't know what it did (it transmits motion data over OSC). I had to make a video showing that it worked. I've had more but I can't remember what they were. :/
|
|
#
?
Jan 21, 2016 20:36
|
|
|
Cool so no big deal, life goes on then? Sounds like a lot of it is resolved with an appeal. My app has the ability to make PDF reports in the documents folder. That should be OK I hope.
|
|
#
?
Jan 21, 2016 20:42
|
|
|
TheReverend posted:Cool so no big deal, life goes on then? Sounds like a lot of it is resolved with an appeal. The takeaway for me is that each submission is a gamble. You may think you're clear because you've only updated something innocuous, but this time around the reviewer might see something differently than the last reviewer. For the most part it's not a big deal.
|
|
#
?
Jan 21, 2016 20:49
|
|
|
Fetching web content into a web view, which content linked to a page which linked to a page advertising a non-Apple payment system.
|
|
#
?
Jan 21, 2016 21:24
|
|
|
The Awful.app reviewer wandered info FYAD and got goatse'd
|
|
#
?
Jan 21, 2016 21:48
|
|
|
And the smilie keyboard, holy poo poo.
|
|
#
?
Jan 21, 2016 21:49
|
|
|
I liked the time that app review suddenly didn't like that Groups wasn't rated 18+ despite having a web view (without an address bar even) that could potentially show 18+ content. In fact I only have a Pinterest account because I produced a "Pinterest->Pornhub in 15s" video as a PoC.
|
|
#
?
Jan 21, 2016 21:54
|
|
|
Subjunctive posted:And the smilie keyboard, holy poo poo. still the best.
|
|
#
?
Jan 21, 2016 21:55
|
|
|
TheReverend posted:So I'm nearning the end of the beta testing phase and we're gonna release soon. The only major cause for concern is if you have a deadline. Give yourself a couple weeks from submission to expected appearance in the store if you have a deadline of any kind. If the app is for a scheduled event or something, you can often request an expedited review, but don't count on it. If you're not racing against a hard date, you try your luck and maybe spend a few days "fixing" things and resubmitting. It's not so bad. Like most things, it's the wait that sucks worse than the action. Oh, and remove the emoji having sex.
|
|
#
?
Jan 21, 2016 23:25
|
|
|
I've taken to just writing haikus for my bug report concerning the un-refusable iOS system alerts. Cold winter morning My morning coffee at work Update? How 'bout now? Demo for full class Projected on the big screen Alert! A new update!
|
|
#
?
Jan 22, 2016 18:52
|
|
|
"Oh! Some activity on my radar!"  "Nope, just a form letter about a new XCode release." 
|
|
#
?
Jan 22, 2016 19:01
|
|
|
lord funk posted:The takeaway for me is that each submission is a gamble. You may think you're clear because you've only updated something innocuous, but this time around the reviewer might see something differently than the last reviewer. Yeah, app review is frustrating not because it's some huge deal, but because it creates a psychological barrier to releasing updates. Instead of just updating and bug fixing continuously, you're stuck weighing the benefits of losing your star rating and risking getting rejected vs fixing that minor bug that a few users have experienced.
|
|
#
?
Jan 22, 2016 19:18
|
|
|
squidgee posted:Yeah, app review is frustrating not because it's some huge deal, but because it creates a psychological barrier to releasing updates. Instead of just updating and bug fixing continuously, you're stuck weighing the benefits of losing your star rating and risking getting rejected vs fixing that minor bug that a few users have experienced. Having done Android releases for a long time a couple of years ago, this is definitely true. One of the few things I miss about Android. Critical bugfix updates are easy. Not so on iOS. Once had a coworker fix a critical bug on an iOS app with a solution that caused an even worse bug. Not fun times.
|
|
#
?
Jan 22, 2016 20:01
|
|
|
Time to expedite the reviews in those cases.
|
|
#
?
Jan 22, 2016 21:29
|
|
|
Since I started developing apps for other people, they've wanted literally 100% of their updates expedited, even for tiny bug fixes. Impatient startup dudes are exhausting to work with. They've actually been pretty successful with it though. According to the people they've talked to at Apple, previous expedited reviews don't hurt your chances of getting another one, so if you make up a sob story each time about how you have to push out this update now or your business will fall apart, it'll usually go through. Hopefully one day Apple will put some resources into improving the app review system, because that kind of abuse sucks, and there's probably enough people doing it that it hurts the review times for non-abusers.
|
|
#
?
Jan 22, 2016 22:51
|
|
|
I've got a maddening Xcode bug I can't figure out. Whenever I have a fix-it appear if I click the gutter icon for it the autocomplete dialog appears and immediately loses focus to the text editor. Next all subsequent text input goes to the text editor with the dialog stuck till I mouse click into it. If instead I click from the issue inspector pane it behaves as expected. This issue survives Xcode reinstallation's, and Xcode setting resets. No plugins and a bone stock Mac OSX. Only happens on my work mac.
|
|
#
?
Jan 23, 2016 05:51
|
|
|
dizzywhip posted:Since I started developing apps for other people, they've wanted literally 100% of their updates expedited, even for tiny bug fixes. Impatient startup dudes are exhausting to work with. They've actually been pretty successful with it though. According to the people they've talked to at Apple, previous expedited reviews don't hurt your chances of getting another one, so if you make up a sob story each time about how you have to push out this update now or your business will fall apart, it'll usually go through. I've actually seen the opposite. My previous company (one of the major consultancy firms) received a message from Apple informing them that they would no longer consider any expedition requests due to abuse of the system. In that case it was down to project managers repeatedly failing to plan review time into schedules, and submitting companion apps for timed events/conferences/etc with one day to go, then asking to be expedited through review. I guess Apple picked up on the pattern in the end.
|
|
#
?
Jan 23, 2016 11:52
|
|
|
Is there a good physical book or beginner's resource for learning Obj-C/Swift/iOS development? My senior project has me designing and building an android and iOS app and while I've done android before, I'm not sure where to start with iOS since I don't have much experience with it. I do use Mac so I have downloading Xcode covered 
FAT32 SHAMER fucked around with this message at 15:44 on Jan 23, 2016 |
|
#
?
Jan 23, 2016 15:32
|
|
|
Tusen Takk posted:Is there a good physical book or beginner's resource for learning Obj-C/Swift/iOS development? My senior project has me designing and building an android and iOS app and while I've done android before, I'm not sure where to start with iOS since I don't have much experience with it. I do use Mac so I have downloading Xcode covered For the languages you'll need to learn, the Big Nerd Ranch Objective-C book is awesome, and I assume their Swift book is good, too. Apple also has a free Swift eBook that's quite good. For the actual frameworks and Xcode, I might just suggest the Ray Weinderlich stuff. I don't know of any good physical books that are up to date at this point (since Apple basically changes the APIs and IDE annually at WWDC), but maybe someone else in here has a suggestion. The free Stanford iOS class on iTunes is always a good bet, too, though I don't know if you like learning from videos or not.
|
|
#
?
Jan 23, 2016 17:01
|
|
|
Kallikrates posted:I've got a maddening Xcode bug I can't figure out. Whenever I have a fix-it appear if I click the gutter icon for it the autocomplete dialog appears and immediately loses focus to the text editor. Persists to xcode beta, is there some global UITextView setting I can reset?
|
|
#
?
Jan 23, 2016 17:27
|
|
|
Honestly Apple's current iOS development tutorial seems pretty good to me. https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/ Definitely seems better than Google's front-and-center tutorial which has you targeting goddamn Android 2.2 or something.
|
|
#
?
Jan 23, 2016 20:41
|
|
|
Kallikrates posted:Persists to xcode beta, is there some global UITextView setting I can reset? If you create and login as a new user does it still happen? At least then you can focus on global vs ~. I assume you don't have Alcatraz or any plugins installed, nor any haxies, strange system-hooking pref panes, etc. Also are accessibility settings at defaults?
|
|
#
?
Jan 23, 2016 21:36
|
|
|
Ender.uNF posted:If you create and login as a new user does it still happen? At least then you can focus on global vs ~. Yeah it was a bone stock Xcode install with nuked Xcode settings - it even persisted through an el Capitan update. As for 3rd party: I don't really run anything that would hook into anything UI. As far as I could tell all the accessibility stuff was default as well. By the time I thought of to try a fresh user account I had already ran `defaults delete -g` which seems to have fixed it I also used 'default find' to look for anything suspicious but that was just stumbling around. The system is my work computer and there is an Admin account maybe some management software they installed did something weird. We'll see if it stays fixed when I go to reconfigure stuff on Monday.
|
|
#
?
Jan 23, 2016 22:35
|
|
|
THC posted:I guess that means I can stop looking forward to the mobile version of foobar2000. Good news! He moved the minimum up to iOS 8 and started using TestFlight for alpha/beta distribution.
|
|
#
?
Jan 25, 2016 10:17
|
|
|
So I'm about ready to submit all my things to Apple for final review for App store. I gotta make the screenshots. Can one just take one screen shot and make images that adhere to all the sizes they need or should I really take a screenshot with the simulator for all the different screen sizes? I don't want to go to apple jail. I'll do the latter if I have to; it'll just require time doing stupid stuff that'd I'd rather not.
|
|
#
?
Jan 27, 2016 05:16
|
|
|
They don't really, strictly speaking, need to be screenshots direct from the app. You can adorn it with some text or whatever, calling out particular features and so on. I guess my answer is: they don't have to be a perfect facsimile of your app on that device. There are also tools to automate screen captures. Here's one I've never tried. Finally, rejected screenshots can be fixed without uploading a new build ("metadata rejected" I think they call it). Still takes a couple days usually for review to come back to it though, same as any other rejection.
|
|
#
?
Jan 27, 2016 06:01
|
|
|
You can change screenshots while it's pending but once it enters review you can't They made that rule because people were making lovely apps and then after approval, changing their app store screenshots to those taken from actual good apps. Basically think of it as once the reviewer lays eyes on your app, you're locked in That said, at an old job, screencapping 5 shots x 5 screen sizes x ~20 languages was A Bad Time
|
|
#
?
Jan 27, 2016 06:22
|
|
|
If you're shipping iOS apps and you aren't using at least some of the fastlane tools you're probably doing a whole bunch of extra work.
|
|
#
?
Jan 27, 2016 06:26
|
|
|
Plorkyeran posted:If you're shipping iOS apps and you aren't using at least some of the fastlane tools you're probably doing a whole bunch of extra work. This is the second time I've see this mentioned this month - I'm going to have to look into it.
|
|
#
?
Jan 27, 2016 06:39
|
|
|
Thanks, IOS goons!
|
|
#
?
Jan 27, 2016 16:44
|
|
|
squidgee posted:This is the second time I've see this mentioned this month - I'm going to have to look into it. Do it, you won't be disappointed.
|
|
#
?
Jan 27, 2016 20:09
|
|
|
|
| # ? May 16, 2024 18:47 |
|