61–70 of 105 posts
Earlier quoted context omitted.
They're better than nothing but compared to the html-esque layouts in Android they're much harder to write, read and debug.
I would beg to differ. I much prefer to work with AutoLayout constraints rather than some custom XML layout like with Android or WP.
Earlier quoted context omitted.
I haven't but I did look at the page as it was linked in the article. I never saw any mention of code formatting. An example of what I expect is like the Eclipse Source > Format option which will go in and make everything consistent including making lines less than 80 chars, adding space around operators (I never put in spaces which goes against almost every style guide), ensuring the arms of if/else always have brac…
AppCode does exactly the kind of source cleanup you describe. It also manages #imports for you, has better code completion, provides a more useful debugger, and gives you refactoring tools almost as good as those available for Java. You can only do iOS dev on a Mac so I don't understand why you consider that an AppCode negative. Considering how much my time is worth as an iOS dev the $99 I spent for a personal licens…
Note that I do do iOS dev on a Mac but I use a combination of emacs on my Linux box using sshfs and command line tools over ssh, plus Xcode when necessary. The product is a library with no user interface so this is actually more productive.
In any event it looks like I should try AppCode. Hopefully it won't have the flaw that stopped me with Sublime Text 2. SL2 didn't detect when a file had been modified outside the editor (eg by vcs or different editor) and happily overwrote the modifications!
I had briefly tried Xcode refactoring before giving up and using search/replace in emacs. One of the curses of multiple languages, client and server etc is that names sometimes end up wrong and need fixing to match local conventions.
Here are the resources I’m using:
Started with: https://developer.apple.com/library/ios/#referencelibrary/Ge...
Then, plan to get a feel of the language will read http://developer.apple.com/library/mac/#documentation/Cocoa/...
Then I was thinking to go watch https://itunes.apple.com/il/course/coding-together-apps-for-...
Also, a book that seems good to read https://www.bignerdranch.com/book/ios_programming_the_big_ne...
Other suggestions and insights are appreciated.
Earlier quoted context omitted.
AppCode does exactly the kind of source cleanup you describe. It also manages #imports for you, has better code completion, provides a more useful debugger, and gives you refactoring tools almost as good as those available for Java. You can only do iOS dev on a Mac so I don't understand why you consider that an AppCode negative. Considering how much my time is worth as an iOS dev the $99 I spent for a personal licens…
I'm doing development at a startup which means minimal funding and a $200 license. My main development system is running Linux and I do development of client side Android and iOS, plus server side (mostly Python), web, database etc. AppCode only helps for one of those, and would be more valuable to me if it ran on non-Mac platforms even just as a better Objective C editor. Note that I do do iOS dev on a Mac but I use…
In any event, AppCode is very good at picking up external modifications because that's how it integrates with XCode.
Thank you. I’m hobby learning iOS development. Have some experience with C, but mostly knowledge of linux, java and devops stuff. Here are the resources I’m using: Started with: https://developer.apple.com/library/ios/#referencelibrary/Ge... Then, plan to get a feel of the language will read http://developer.apple.com/library/mac/#documentation/Cocoa/... Then I was thinking to go watch https://itunes.apple.com/il/cou…
I would add Crashlytics ( http://try.crashlytics.com/ ) to the list of good crash reporting services.
Don't know how things are with Testflight right now but when we worked with them last year we had to right our own script to upload the dSYM. Also Testflight does a lot more than just crash reporting so it might be too big a hammer if you just want automated crash reports.
Good article, I like these because there are a lot of things I wish I knew when I started iOS development as well 'back in the day' :) Couple nits: -XIBs are awesome and you should strive to use them, falling back to layout in code when the XIB fails to meet your requirements. Though I'm also finding storyboards hard to swallow for complex projects. -Blocks and GCD are great tools but with great power comes a lot of…
Earlier quoted context omitted.
Have you tried JetBrains's AppCode? http://www.jetbrains.com/objc/ (I haven't but their RoR-tailored IDE RubyMine is the only IDE I've enjoyed using after it for less than a week.)
I haven't but I did look at the page as it was linked in the article. I never saw any mention of code formatting. An example of what I expect is like the Eclipse Source > Format option which will go in and make everything consistent including making lines less than 80 chars, adding space around operators (I never put in spaces which goes against almost every style guide), ensuring the arms of if/else always have brac…
$200 is you purchase a company license, which means anyone at the company can use it. If you are the only person using it, you only have to pay $100.
A surprisingly good list. Beyond the xib issue, which other have talked about, I would add a couple of points: - If developing a trivial utility app you're expecting to release quickly, target iOS version N-1. Any user who is more that one major iOS version behind won't be the type of user who will download your app (or any app really). If developing anything more ambitious, target the latest iOS version only and tak…
Once you've published your app as universal, there is no way back. You can't decide in a subsequent update to revert to an iPhone-only or iPad-only app - Apple won't let you.
So if you start with an iPhone app, and then put together an iPad version of the UI just to try out and publish it as a universal app, you'll be stuck with having to provide an iPad version of your app for the rest of times. Even if you realize that the iPad version isn't worth it for your app and that nobody uses it, you won't be able to discontinue it.
So think very carefully before flicking that switch.