Cocoa Chronicles #1: ActionScript vs. Objective C

Skip Intro

*** Update: Paul Taylor (@guyinthechair) has a more recent post on the same subject. ***

*** NOTE: I’m a n00b at Cocoa and Objective C. Unlike Python, I don’t like learning it, either. If you perceive something below is inaccurate, please comment, and I’ll update. ***


I was having a lot of fun using the iPhone packager. Then Apple changed their licensing to prevent people like me from using ActionScript for iPhone/iPad, and instead being forced to use their toolsets, or those unofficially approved. At first I was furious. Then I tried to get a simple list to scroll in AS3. Even using a fake mask, device fonts, and cacheAsBitmap for all items + container, it just wasn’t smooth, even with just 30 items, regardless of frame rate. If you use an out of the box UITableView in Cocoa, it “just works”.

I built my career on Flash Player because “it just works”. It doesn’t “just work” on the iPhone, and now it’s effectively illegal to use. That, and Adobe has apparently abandoned ship on the iPhone/iPad/iTouch portion, and instead are focusing on Android.

I was amazed at what I could do using Flash Lite 2 on my Nokia 6680 3 years ago. AS3 was all the rage, and yet I took the time to build a component framework in AS2 for use on devices because I felt it was “good enough” to build experiences for consumers. That market never materialized unless you targeted Japan (which I didn’t).

After finally getting my simple SWF to compile to the iPhone, I was estatic at how easy it was to design & code in what I knew, it just worked, and looked like I expected it to. Once I started moving things via TweenLite, though, it all went downhill. I don’t have these problems in Flex. If I use a List control in Flex, it just works; I don’t have to be an AS3 game developer to theorize on GPU acceleration possibilities to get the best list scrolling performance. I don’t have these problems, at least from what I’m initially seeing in my early learnings, with Cocoa.

So, I’m learning Objective C so I can execute the ideas I have for iPhone and iPad. Unlike PHP, Ruby on Rails, and Python & Django, this has been a pretty miserable experience. Python and Django are my choices for back-ends currently… but I don’t really have a “choice” for front ends on iPhone/iPad.

In an effort to reduce the pain for others as well as help myself retain this knowledge, I’m writing it down.

I understand it might seem strange since Android is a lot easier to develop for, and Flash Player 10.1 actually runs natively on the phone… and well, I might add. For me, there are 3 reasons. First, there is no market right now. Yes, I understand we help create it, but I own an iPhone and iPad. I love them, and so do others. I have a gateway to others right now via the app store, and want to empower them to use my apps. Secondly, if you’ve ever used an iPad, the additional screen real estate just fills you with ideas. Third, everyone wants an app right now. While the consumer data shows it’s hard to make money, it’s REALLY easy to make money for services; aka, a company hires you to build an app for them. This is especially true with the OS4 announcement of Enterprises having more control over deploying their own applications.

Another good primer for me, Objective C for the ActionScript Developer, is Keith Peter’s five tutorials. He doesn’t really cover the UIKit, just Objective C in general which is a great first start.

  1. AS3 to iPhone Tutorial 1
  2. AS3 to iPhone Tutorial 2
  3. AS3 to iPhone Tutorial 3
  4. AS3 to iPhone Tutorial 4
  5. AS3 to iPhone Tutorial 5

Introduction: Nomenclature

There are a lot of new terms to learn. I just want my code to run on the iPhone, yet I have to learn a bunch of new terminology to ensure I understand what it entails, as well as their “meaning”. For example, MVC means something different to Objective C guys than it does to us. Yes, it’s subtle, but when they say it, it’s assumed you mean “their” version. It helps to know what the nomenclature of the Cocoa community is to learn, so first up, here’s some common terms.

Cocoa: The API you code in for the Mac. It’s like saying “Flex”; it’s all the things that fall under “Flex” like the compiler, the sdk, the ide, the runtime, etc. However, it’s a lot more than that. For example, there are Human Interface Guidelines that Apple puts out that Cocoa apps need to comply with (I don’t currently know how this is enforced, excluding iPhone/iPad). For the sake of this article, all you care about is “Foundation” and “UIKit”, 2 libraries that make up a lot of what people know of as Cocoa for iPhone. It’s also built on the MVC concepts we’re used to. The main difference is Cocoa is huge; it is a layer atop an OS, whereas Flex is a layer atop the Flash Player.

Objective C: C like programming language you code in that borrows some cool things from Smalltalk, similar to how we code in ActionScript. It’s from the 1980’s, and boy does it feel like it. Anytime I start coding, I have Megadeth on in the background, my Pontiac Firebird Trans Am in the driveway does a turbo boost, and Fletch watches over me, commenting how it’s all ball bearings these days.

Foundation: Provides all the low level stuff you need and shouldn’t have to write yourself. This includes data types like NSNumber (vs using int/float yourself), sockets, etc. Basically, if you can’t see it in a GUI, the class is here. Everything is prefixed with “NS” for NextStep, one of the companies responsible for the early development.

UIKit: All your GUI controls including support classes. Things like UIButton, UIAcceleration, etc. The UI prefix stands for User Interface (duh). You’ll hear about references to Application Kit; that’s the desktop version.

Core Data: Basically the model layer of your apps. This is actually kind of cool, and what we should have in Flex (I know of 2 people who have tried to create an open source one, and then shortly thereafter abandoned the project… too bad too). Right now, there are things like it in LiveCycle, I believe, but only Enterprises can afford that, so its’ not for “everyday use”. Basically, you create ValueObject’s, and they can be persisted in local XML or SQL databases automatically, vs. you having to manually write Factories, parsers, and versioning. Pimp.

Xcode: The IDE that you code Objective C in. You can build & debug your iPhone/iPad applications directly from here.

Interface Builder: The IDE that you use to visually build your GUI apps. You can actually create variable & method definitions here, wire them up visually, and then have it code gen the classes for you. It can also read your header files (imagine if every ActionScript class had an interface class associated with it that defined what it did). As a n00b, I’ve found it really easy to confuse this program and make it explode. Also, someone forgot to add tab order when they made it.

Objective C

Objective C is the programming language you write your applications in. It is effectively an extension to ANSI C with Object Oriented syntax. In Flash and Flex, you utilize ActionScript 3. Objective C has a lot in common with C and C++, and some of the lamesauce as well, namely pointers. Objective C also has multiple environs it can run on while ActionScript runs in just the Flash Player.

If you know ActionScript 3, you can read C, and thus Objective C. Like Java, the type definitions are on the left instead of right, but other than that, they are extremely similar. Like another article mentioned, if C didn’t have pointers, PHP and C would be nearly the exact same. Since Objective C has a lot in common with C, they too are similar.

If you’re coding Objective C for the iPhone/iPad, you don’t get Garbage Collection, and have to manually get rid of your variables/objects. Once you get used to the syntax, it’s almost the exact same as cleaning up your mess in ActionScript. In ActionScript, you set your Object references to null; in Objective C it’s called nil. More on that insanity later.

You can read more here about here.

Yes, you code in Objective C 2, not 1. 1 is even more lame than 2 (thankfully?).

Objective C Syntax: Methods

Objective C has a lot of the same things that ActionScript 3 has. They both use the same bracket syntax, and have the same cuddled vs. not wars. They both end lines with semi-colons. There isn’t as much dot syntax. They both have methods. Here’s how you invoke one in ActionScript:


Here’s how you invoke it in Objective C:

[mySound setVolume];

Notice in Objective C, they use brackets to indicate the containment of a method call. You can nest these as well, but they recommend you only go 2 deep since it becomes un-readable after that.

Here’s ActionScript storing a return value:

volume = mySound.getVolume();

Here’s Objective C doing the same:

volume = [mySound getVolume];

Passing in parameters is a little different and takes some getting used to. This, to me, is the same thing that threw me off in Ruby, and where Objective C totally ignores how C does it. Here’s ActionScript:


And here’s Objective C:

[mySound setVolume:value];

Ok, not so bad… except, the 1st parameter is always the only one WITHOUT a named parameter. Observe the following ActionScript 3 function with 2 parameters:

mySound.setLeftAndRightPan(left, right);

…and Objective C:

[mySound setLeftAndRightPan:left, rightValue:right]

Notice there is no “leftValue:left” here, just left. The first parameter is always nameless, yet every one after it has one. I guess they wanted more obvious parameters during function invocations… except forgot to build in one for the 1st parameter. *face palm*

For example, here’s an ActionScript 3 function definition:

private function setLeftAndRightPan(left:Number=0, right:Number=0):void

Here’s the equivalent Objective C:

- (void)setLeftAndRightPan:(NSNumber*)left, right:(NSNumber*)rightValue

Notice 4 important things. First, the return type is in the beginning and wrapped in paranethesis (void in this case). Second, notice that Objective C doesn’t allow for default values for function parameters like ActionScript. Third, notice the type definitions for the function parameters are in the left side vs. the right (in this case NSNumber). We’ll get to the asterisk later. Fourth, notice the dash in the very beginning. That signifies that this is an instance method on the class. If you want ActionScript’s static, use + instead.

Objective C Syntax: Variables

Variables are slightly different because Objective C has pointers as well of built-in helper methods to make memory management easier.

Here’s a variable in ActionScript, first defined using a String literal (pimp syntax) and the old school way:

private var name:String = "";
private var name:String = new String();

And here’s one in Objective C:

NSString* name = [NSString string];

There are a ton of caveats here. Notice we’re calling the string method on NSString; it’s basically a factory method to give us a string; similar to going new String(). When I did “” above, it’s called a String literal; the same as going {} vs. new Object(), or [] vs. new Array(). In ActionScript, each of those constructors has nice features, the effect is the same; you get a variable of that type back.

Notice the asterisk in the Objective C example. This means it’s a pointer to the String, not the actual String. Also notice since we’re calling the string method on the NSString class, it’s autoreleasing (similar to the Doom spell in Final Fantasy; it’ll die soon; ie he’ll get ejected from the Pool soon, more on that later). If you want the guy be like Number 1 and live forever instead of a Rico’s Roughneck, go:

NSString* name = [[NSString alloc] init]

Just keep in mind you have to manually call release on him later whereas the former, you don’t.

Objective C Syntax: Pointers & Memory Management

Variables are different because of a couple reasons. First, since Objective C is based on C, it has all the pointer baggage. We ActionScript Developers are spoiled because we don’t have do deal with this… or if we do, it requires little thought.

For example, in ActionScript, there are only 3 variable types that are by value, and thus don’t have pointers: Strings, Numbers, and Booleans. Yes, I’m including int and uint as Numbers here. Every other construct is an Object, and thus is passed by val. If you wish for an Object based variable to be removed from memory eventually, you need to ensure no more references exist, or in the case of circular references, that no one else knows about the circular relationship (the Mark and Sweeper from the Garbage Collector will get those mofos). For Numbers, Strings, and Booleans who aren’t local variables, you just remove their parent Object, and they’re toast. For local variables, they go away at the end of the function (usually… depends on how aggressive the Garbage Collector is at that moment in time).

For Objects, you just remove all references, usually by setting them to null, or in the case of dynamic Objects like Dictionary or Object hash maps, using the delete keyword.

Objective C’s iPhone runtime, and ActionScript’s Flash Player both operate using reference counting. This means, for Objects, an internal number is incremented for every person who “knows” about an Object. When that person later set’s his reference to null, that reference count goes down. When that reference count reaches 0, it’s eligible for Garbage Collection. The Flash Player also has a Mark and Sweep part to take care of circular references in the case where 2 Objects know about each other, yet no one knows in your app knows about them, and thus their reference count will never reach zero. If you’re running on the iPhone, you don’t have Garbage Collection, so need to call release yourself (which calls dealloc internally). In ActionScript, you’d either null the reference out, or call your own destroy method, THEN null reference out.

Objective C has this built in as a method called dealloc. You don’t call, it gets called for you when you (or someone else) calls release. In ActionScript, people will either use a convention of public function destroy, or those fu@#(* IDestroy marker interfaces that people NEVER implement fully (did I mention that’s annoying?).

In ActionScript, for a complex class, it may look something like this:

public function destroy():void
timer.removeEventListener(TimerEvent.TIMER, onTick);
timer = null;

In Objective C, this is built-in to NSObject, one of the main classes you often extend. The Objective C version of the above would look like:

[timer release]
[icon release]
[super dealloc]

As learn about how getter/setters are built into Objective C, you’ll see there is a better, and more common way to do the above (article I link to at the bottom describes this), but I need to get the point across here that you’re expected to clean up your own mess since Garbage Collection doesn’t exist, and everything can’t be an autorelease variable.

No Local Variables, Hence Autorelease & T3h Pool

In ActionScript, we have local variables. Basically, instead of storing it in memory, it’s stored in temporary memory that the stack is using (the stack of functions currently running). When one stack item is done (your function is done), those variables are removed. In ActionScript’s case, this isn’t immediate, but basically ensures that no one has references to those variables anymore. Later, Garbage Collection will come along and eat’ em.

Objective C doesn’t have local variables. Yes, I know, I’m face palming as well.

*deep breath* There IS a common way to deal with it. Your first thought may be to create a bunch of member variables; basically what game developers do for simple Object Pooling. That’s ghetto, though. You may think you could just create variables on the fly… the problem with that is you have to manually release them, and for return values, they’ll die before they get returned.

This is where autorelease comes in. Remember before when I talked about the 2 ways to create variables? Let’s revisit it, and show again how you kill things.

This creates a variable you must manually remove:

NSString* name = [[NSString alloc] init];
[name release];

… and she’s dead. However, here’s one that’ll be added to a pool, or rather “a Pool”:

NSString* name = [NSString string];

This is the same as doing:

NSString* name = [[NSString alloc] init];
[name autorelease];

You can then safely return these variables from functions, knowing that the caller will get it. It’s also considered good practice to do, specifically for encapsulation. There isn’t really a language construct to say “Hey dude, this guy is going to send you a variable it also has a pointer to, so please make sure you call his release first”. Crap like that is insane; it’s just easier to get either copy’s of variables so you don’t inherit their pointer baggage, or use autorelease so you don’t piss off people getting variables from you, and causing leaks if they forget to kill you first.

Yes, all of that above is a shortened version of what you have to do because there are no local variables. Yes, I’m face palming again.

If you’re curious about what this Pool is, imagine if a static class was created every time you ran some code.. and Garbage Collection ran immediately when you null’ed out your variables. The first thing it did was keep a reference to any variable that has autorelease on it. Then, 1 frame after the stack has been complete (all your code has run, and the next enter frame runs), it kills all the variables it has stored. That’s the AS version of what an Objective C Pool is.


This sucks. I blame Adobe AND Macromedia for my suffering.

BTW, if you’re looking for some pimp tutorials to learn this stuff, my compadre Brian linked me to it, called “Cocoa Dev Central“, specifically this article.

28 thoughts on “Cocoa Chronicles #1: ActionScript vs. Objective C”

  1. Objective-C is an old language, and as such, it lacks a lot of features we are used to after working with modern languages for a long time. For example, I had to re-learn pointer and memory management all over again.

    I remember when I first started learning ObjC and Cocoa, I found Interface Builder to be incredibly confusing and XCode to be a pretty weak code editor. Now that I know better and have made a few apps, I still think those apps suck. But those are the only tools we have…

  2. I’m getting corrected on Twitter. So, 2 modifications.

    …there are local vars but it’s a memory managed environment

    Also, comparing Objective C’s NSString to ActionScript’s String isn’t a correct comparison; using NSMutableString would of been more accurate.

    I’ll cover mutability in another post since it’s way too large for this one.

  3. Hi, nice comparison from the AS perspective.

    A couple of comments:
    – You got Objective-C messaging backward. There is no named parameters in Objective-C. Instead, you should view messages as english sentences with holes in them that you fill with arguments. Thus, the equivalent to mySound.setLeftAndRightPan(left, right); is [mySound setLeftPan:left rightPan:right].

    – Objective-C actually have local variables (as a superset of C, which have local variables). Your are confusing reference counting based memory management with local variables. Those are two different and unrelated things.

  4. I was able to create a dual-tier scrolling list with AS3 and the iPhone-packager just fine. I don’t see why you would try to use the Flash/Flex components in any project where optimization is required. Performance just wasn’t an issue on the iPhone, as seen with the video below, as long as you practiced fairly common optimization techniques.

  5. @Paul Thanks for the clarification Paul. When I said named parameters, I meant Objective C methods have names for invocations whereas with ActionScript, you do not. For example, I have no clue what this does:

    mySound.setPan(value1, value2);

    But in Objective C, I do:

    [mySound setPan:value1, rightValue:value2];

    That named parameter allows me to quickly deduce what value2 is actually going into. Yes, it’s a horribly written variable name, but that method invocation is a lot clearer than it is in ActionScript; something I think AS coders would like… or maybe not… :: shrugs ::

    Regarding locals, thanks. Still don’t get it, but maybe in 6 months I will.

  6. @leef I didn’t do anything out of the ordinary. Just 30 Sprites with a Loader and 3 TextFields in them. I wasn’t using Flex components at all, straight vanilla AS3.

    Not saying I don’t believe you, but you can’t just post a video like the HTML5 guys and say it’s real; please post code so we can validate your claim.

  7. I’ll agree though, if your project requires the absolute best performance & API access for your iPhone app, use Objective-C & XCode. Though for a huge number of apps, it’s just not necessary, and they run great being made with the Flash authoring tools & AS3.

  8. Use cacheAsBitmap=true on those Sprites, and set sprites that are offstage to visible = false. That’s probably it. Send me your project, I’ll make the changes myself, and send it back with solid performance tweaks = )

  9. Method signatures should be setLeftPan:rightPan:, so that you do name the first argument. If you look through the API, for the most part this is followed. In addition, there is no need for default values in methods, because you simply leave off the parameter and have that method call into your main method. For example, [obj setLeftPan:0] calls [obj setLeftPan:0 rightPan:defaultValue].

    In addition, you mention that cleaning up objects is as simple as assigning nil to them when there’s no GC, but in actuality, you need to call [obj release] on them in that case.

  10. @Stephen Thanks for the clarification. It’s kinda sinking in.

    Regarding release, I didn’t go into details, but I was referring to synthesize’d getter/setters and calling [self variable] = nil in the dealloc method as a shorthand way of not having to both call release AND setting the private to nil. Sorry I didn’t explain that better, but to be fair, I’m pretty sure I can’t at this point since I still suck at this.

  11. I think the part you’re missing for understanding the local variables part is the heap. You talk about the stack and its temporary nature, and that’s right, but there’s this other part of memory that is basically used to store stuff that is meant to live longer than a function call and/or objects that take up a lot of space.

    Every time you call new SomeClass() in Actionscript you’re creating an object that will be stored in the heap. You get back a reference to this object, so you have a way to access it and do something useful with it. That reference is stored in a variable.
    Consider this Actionscript:

    function createPoint():void {
    var p:Point = new Point();
    p.x = 10;
    p.y = 20;

    What happens here is:

    1) A Point object is created. Meaning some memory is allocated on the heap. Other things are going on like construction / initialization, etc
    2) A reference to this object is returned and stored in a local variable, p, that lives on the stack.
    3) You de-refence p to access the object created in step 1) and manipulate it. In other words, you are using a local/stack var that points to an object that is somewhere else, in the heap.
    4) After the function returns, the local var p will go out of scope. The stack memory used by it will be eventually overwritten, but it’s basically gone, you can’t count on it. The Point object, however, is still allive. If no one holds a ref to it, it’s unreacheable and eventually will be collected automatically.

    Now, in C, it’s very similar (At this point I should say I haven’t written a line of Obj-C in my life, but I’ve coded a bit in C -not profesionally- and hopefully the same basic mechanisms apply to Obj-C).

    void createPoint() {
    // Point is defined somewhere else; think of it as a kind of VO with 2 fields
    struct Point *p = malloc(1 * sizeof(struct Point));
    p->x = 10;
    p->y = 20;

    1) Similar to Actionscript, except you have to tell the allocator how much memory you want. This is automatically handled for you in AS. In Obj-C, you call alloc on the object instead of the global malloc function. After this, you get a chunk of memory that contains gibberish; you should initialize it in some way that makes sense in C. If I’m not mistaken, this is what init does in Obj-C. So, in Actionscript, construction works in one step: new() allocates memory and initializes the object in some meaningful way (using default values). In Obj-C, these are two separate steps (as in C): first you allocate some memory; then you initialize it.
    2) Similar to AS, again. Instead of a reference, you get a pointer. The concept is very similar, except that it’s way easier to screw up or do stupid (and possible dangerous) things with pointers. Basically, a pointer is a variable that holds a memory address. Think of the heap as big global ByteArray and the pointer as the index where your object was put.
    3) Same as AS, but replace reference with pointer. The “->” syntax is a shortcut for “take this pointer, fetch the object it points to, and access this field”. So, following the ByteArray analogy, it’d mean something like: _heapMemory[address].x .
    4) The same as AS, except for the last sentence. Since there’s no automatic garbage collection, if you do this in C you have a memory leak.

    If you’re done with your object, you should call free(p), to return the memory back to the heap.

    Now, if you return the pointer, at some later point you’ll have to free it (you or whoever is calling your function) or, again, you have a leak. As you say, this is where it tends to get hairy, because you have to think about who’s got to free up stuff, and if your object (or more precisely a pointer to it) is in turned passed back to another function, returned to another caller, etc… well, it can easily get hard to follow who owns what (and so, who’s responsible for releasing / freeing up the thing).

    In Obj-C, though, you have a mechanism to alleviate this, the autorelease pool. But I’ll leave that someone who actually knows and has worked with the language, because I have only a vague idea of how it works.

    Back to the local variables thing, as I said, C and Obj-C do have local / stack variables. And in fact, you can avoid pointers / heap memory and just use stack / local memory in some circumstances (say, if you’re using an object only inside a function and this object is not too big).

    void createPoint() {
    struc Point p;
    p.x = 10;
    p.y = 20;

    Notice there’s no asterisk (and consequently, “.” is used instead of “->”). Here, the point object itself lives in the stack; there’s no heap allocation and the memory the point object takes up in the stack will be “freed” (actually, reused) after the function returns. The problem with this is that its usefulness is limited. If you want to return p… well, don’t, because your program will most likely blow. You’d be arbitrarily reading from or writing to memory you shouldn’t be messing with (the stack), because is used to control the execution flow; you could overwrite a return address with random crap, for example, and then you can’t know what will happen next (or maybe you could if you did on purpose, but let’s assume you don’t want to exploit your own program).

    Well, I hope this ramble makes any sense at all.

    Juan Pablo Califano

  12. @Juan Wow, thanks Juan, this is good, helpful stuff! I’m not sure how C programmers actually get things done having to deal with this insanity, but hopefully it pays off in app performance.

  13. This “insanity” is characteristic of lower-level languages, i.e. those that more closely represent what really goes on in the computer. That’s why UNIX itself is written in C; it has higher-level features but still can deal directly with memory at the byte level. I’m sure you are already seeing how the AS3 syntax gives you more protection and less power. We already have to clean up our instance variables in AS3 by ensuring they’re available for freeing; in the C languages we just have to take the final step ourselves and free the memory explicitly.

  14. “Every other construct is an Object, and thus is passed by *val*” Should it be *reference* instead?

  15. I started my career with C and after about 3 years moved on to Java. 10 years later I start to think retrospectively about Java vs C and god-damn I know realise what a lazy programmer I am.

    Don’t fear memory management and pointers, it can only make you a better programmer, even if your #1 programming language doesn’t have them.

    Btw, your point on UI Guidelines – they’re just that. They’re not enforced. It just depends if you want your app to truly feel part of the Mac eco system. A lot of developers work cross-platform, so would rather have a consistent of their app regardless of platform and this is fine. AIR is a great way of doing that, in fact.

  16. Hi Jesse

    Good to see you’re getting your hands in the engine with pointers and heap/stack …

    As you know we have created ELIPS Studio to help AS3 developers avoid getting their hands dirty with this stuff

    Still you can code in ObjC to create natuve extensions and mix ObjC with Flex/AS3 code

    Would be great to get your feedback on this mechanism now that you start being proficient in ObjC

    As an aside, you can also look at this interesting discussion on our Forums about how C++ code generated from AS3 with ELIPS Studio is 5x faster than ObjC:

  17. “This sucks. I blame Adobe AND Macromedia for my suffering.”

    I read this article fully expecting it to say how easy actionscript is and how that spoils us for other languages…turned out to be quite the indictment of Adobe. It put a few cracks (especailly as it was referenced by the Jester)in the foundation of my loyalty wall w/Adobe.

    I still don’t like the closed system Apple is trying (has) to build. I hope Android and the dozens of Android devices, colectively become a strong competitor to the iFamily.

  18. @Guilhem

    start being proficient in ObjC

    I lol’d. I’m barely capable of compiling still, but thanks for encouragement!

    Yeah, I’ve messed with ELIPS a few times. The lack of MovieClip was depressing, but bearable. However, I wasn’t getting very good transition performance moving simple View’s back and forth so gave up.

  19. @Mark I do love ActionScript; next to Lingo, I grew up with it. I also love Python, and PHP is a cool friend too. JavaScript is great, just has crappy visual runtimes; if it had a DisplayList vs. this DOM/HTML/browser insanity, I’d probably be doing web dev.

    And yes, now that I have context, it’s amazing the amount of work it does for us, yet still gets great performance for what we throw at it.

    If you read the beta + public forums, Twitter, and blogs, the Flash & Flex community is pretty pissed right now at Apple. It has driven most who were developing for iPhone to now develop for Android instead, including those who weren’t doing mobile development before. It’s a real shame, too, because we have a higher concentration of designers & UX people in our industry than in others… and now those resources are going towards Android vs. iPhone.

    Me? I love my iPhone & iPad too much to abandon ship, and still see wonderful potential for some apps I’d like to build… so am suffering through it. Besides, learning to developer for Android based on what I’ve seen is WAY easier and requires less time, less blood and tears.

  20. I thought I read somewhere that the latest version of Objective-C now supports the dot notation. It might you have to turn it on in some settings panel somewhere.

  21. @Jesse
    > I wasn’t getting very good transition performance moving simple View’s back and forth so gave up.

    That surprises me. In our bench we get really fast performance (even faster than ObjC!).

    On a 3GS, we do not see noticeable difference from native UI.

    There are numerous performance optimisation tips on our Forum.

    One notable tip is to move UIComponents and not Sprites. This way you benefit from GPU redraws. See:

    We recommend using “UIComponent” as the base drawing class

  22. fuck off with objective c. its old as shit and it sucks! worst part is apple’s documentation and that xcode click-drag i feel like stephen hawking. let them force you to learn it. apple is hypeing big against flash because they know that its the better choice. you could run the whole iphone with one .swf

Comments are closed.