3 ms·

Honest question: are they really easier to make? I know almost nil about iPad apps. The only thing I know is that they might be coded in Objective-C... which

Honest question: are they really easier to make? I know almost nil about iPad apps. The only thing I know is that they might be coded in Objective-C... which I know nothing about. But I do know about Rails, and I know it's dead simple once you get the hang of it. It took me about 3 or 4 months to get the hang of with no real prior programming experience, and now I could definitely code an app like this in a weekend. That seems pretty damn easy to me. > it's easier to make money off of them well, you've got me there :)

dikbrouwer 16y ago
Although it may sound unintuitive since Objective-C is indeed a bit more cumbersome vs. your average web stack: yes. I do think it is easier in a way to design/develop apps with a great UI on iOS devices. The point is not Objective-C, but 1) Cocoa Touch comes with a very well though out UI library that you can use/subclass, and it comes with very specific interface guidelines. I think Apple did a terrific job here. Realize that not all touch devices have great interfaces (some BlackBerry apps for example). It's the iOS apps that tend to be very well designed. 2) A touch interface in general allows different UI elements to just 'work better'. Scrolling a tableview or swiping a carousel window (vs. clicking 'next page' on a website) is a more logical choice on the iPad/iPhone than on a Desktop where you interface with a mouse and keyboard.
stcredzero 16y ago
I know almost nil about iPad apps. The only thing I know is that they might be coded in Objective-C. I have to say that for fast iteration and explorative development, Ruby has it over Objective-C. I say this even though I very much like Objective-C and the iOS SDK. Objective-C is like C++, but with a (IMO) better attempt to bolt the late-binding goodness of Smalltalk as the Object Oriented part, instead of the more complicated machinery of C++. The iOS SDK is like the best of Object Oriented Design from the early 90's, powered by an elegant message passing infrastructure, allowing clean implementations of patterns. Unfortunately, there is still a lot of stiffness from its statically typed roots. Iterative development is slower than for a dynamic language. It's very good, and I think XCode is a top-notch IDE. I even have an SSD for the purpose of making the Edit-Compile-Debug cycle as fast as possible. Despite this, investigating runtime behavior is still 2 to 3 times slower than in a dynamic language, refactoring is more work because there is more syntax and more repetition of entity names in different files, and there is more need to know how everything is laid out up front. I'm facing this situation right now with converting my little calendar app to use a paged UIScrollView. You have to know a lot of how the UIScrollView works up front. I was able to get it to do the "Page Transitions" from month to month just by changing the data underlying my view. Now that I want to switch between different calendars with a sideways swipe, I have to create multiple views to do that, which involves yet more data refactoring. I had already refactored to support an array of multiple calendar objects in my view. Now I need to have multiple views with one calendar each. In a dynamic environment, I would be done already even without knowing this up front. > it's easier to make money off of them Look at the history of technology. This almost always trumps the more elegant technology. An ecosystem which rewards developers with money or some other satisfaction results in a virtuous cycle which results in more value created for the technology, which in turn makes it easier to create even more value and get rewarded. EDIT: Another example. Look at the code it takes to increment a Date by 1 month. That is, I want to go from day N of month M to day N of month (M+1). It seems simple, but there's a bit going on there. In Ruby, this is one statement. In Objective-C with the iOS SDK, this involves three objects. To be fair, the iOS version is more powerful and flexible, which will let your code run correctly, even if you do something far-out like suddenly switch to a lunar calendar. 99%+ of developers won't ever benefit from that.
aerique 16y ago
Honest question: are they really easier to make? I was using some hyperbole to get a discussion going, but unfortunately this item has dropped off the homepage. What I meant: Making a basic prototype for a GUI app is perhaps easier in the browser, but IMHO the whole road[1] to a finished application is easier for an iOS app. [1] front-end, back-end, payments, distribution, multiple browsers / OS problems

dikbrouwer 16y ago

Although it may sound unintuitive since Objective-C is indeed a bit more cumbersome vs. your average web stack: yes. I do think it is easier in a way to design/develop apps with a great UI on iOS devices. The point is not Objective-C, but 1) Cocoa Touch comes with a very well though out UI library that you can use/subclass, and it comes with very specific interface guidelines. I think Apple did a terrific job here. Realize that not all touch devices have great interfaces (some BlackBerry apps for example). It's the iOS apps that tend to be very well designed. 2) A touch interface in general allows different UI elements to just 'work better'. Scrolling a tableview or swiping a carousel window (vs. clicking 'next page' on a website) is a more logical choice on the iPad/iPhone than on a Desktop where you interface with a mouse and keyboard.

stcredzero 16y ago

I know almost nil about iPad apps. The only thing I know is that they might be coded in Objective-C. I have to say that for fast iteration and explorative development, Ruby has it over Objective-C. I say this even though I very much like Objective-C and the iOS SDK. Objective-C is like C++, but with a (IMO) better attempt to bolt the late-binding goodness of Smalltalk as the Object Oriented part, instead of the more complicated machinery of C++. The iOS SDK is like the best of Object Oriented Design from the early 90's, powered by an elegant message passing infrastructure, allowing clean implementations of patterns. Unfortunately, there is still a lot of stiffness from its statically typed roots. Iterative development is slower than for a dynamic language. It's very good, and I think XCode is a top-notch IDE. I even have an SSD for the purpose of making the Edit-Compile-Debug cycle as fast as possible. Despite this, investigating runtime behavior is still 2 to 3 times slower than in a dynamic language, refactoring is more work because there is more syntax and more repetition of entity names in different files, and there is more need to know how everything is laid out up front. I'm facing this situation right now with converting my little calendar app to use a paged UIScrollView. You have to know a lot of how the UIScrollView works up front. I was able to get it to do the "Page Transitions" from month to month just by changing the data underlying my view. Now that I want to switch between different calendars with a sideways swipe, I have to create multiple views to do that, which involves yet more data refactoring. I had already refactored to support an array of multiple calendar objects in my view. Now I need to have multiple views with one calendar each. In a dynamic environment, I would be done already even without knowing this up front. > it's easier to make money off of them Look at the history of technology. This almost always trumps the more elegant technology. An ecosystem which rewards developers with money or some other satisfaction results in a virtuous cycle which results in more value created for the technology, which in turn makes it easier to create even more value and get rewarded. EDIT: Another example. Look at the code it takes to increment a Date by 1 month. That is, I want to go from day N of month M to day N of month (M+1). It seems simple, but there's a bit going on there. In Ruby, this is one statement. In Objective-C with the iOS SDK, this involves three objects. To be fair, the iOS version is more powerful and flexible, which will let your code run correctly, even if you do something far-out like suddenly switch to a lunar calendar. 99%+ of developers won't ever benefit from that.

aerique 16y ago

Honest question: are they really easier to make? I was using some hyperbole to get a discussion going, but unfortunately this item has dropped off the homepage. What I meant: Making a basic prototype for a GUI app is perhaps easier in the browser, but IMHO the whole road[1] to a finished application is easier for an iOS app. [1] front-end, back-end, payments, distribution, multiple browsers / OS problems