Cross With the Platform

Tim Bray tweeted, No platform has hit the big time till it's been flamed by JWZ. He was referring to this rant in which Zawinski systematically dismantles any claim the iPhone has to cross-platform compatibility. "I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it's safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS. ... they got some intern who was completely unfamiliar with the old library to just write a new one from scratch without looking at what already existed. It's 2010, and we're still innovating on how you pass color components around. Seriously?"

Comments

Could be worse

[BadAnalogyGuy]

It could be much worse. You could have all that legacy crap left in the OS bloating up the system and wasting space.

Windows Mobile may have a backwards compatibility advantage over iPhone/iPad/OSX OS, but really, do we want to start holding a Microsoft OS up as an example of something done *right*?

Re:Could be worse

[Adolf Hitroll]

do we want to start holding a Microsoft OS up as an example of something done *right*?
yes
otherwise you're blind.

Re:Could be worse

[BadAnalogyGuy]

No, yuo.

Re:Could be worse

[Bert64]

Windows mobile probably has more of a backwards compatibility problem than the iphone... The core OS of the iphone is the same as normal OSX and it's only the interface APIs which are different - and rightly so, the whole interface is fundamentally different in how you interact with it.
Windows mobile on the other hand is a whole different os with a completely different kernel.

Re:Could be worse

[beelsebob]

The only valid complaint I see in this whole article is with NSColor/UIColor – NSColor really should be in the Foundation API (common to both Mac OS and iPhone OS), not the AppKit/UIKit APIs.

His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!

As for UIKit being very different from AppKit... Well of course it is! UIKit is for building touch based UIs, if you transfer the exact same things as you have on Mac OS straight over, you end up with a shit mishmash of rubbish. The important thing here is that both APIs share their Foundation API (the basic programmery stuff you need like dictionaries, arrays, strings, etc).

Re:Could be worse

[blackraven14250]

Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!

Unless I'm missing something, or you're living in 2020, OpenGL version 2 was released in 2005, and you're 10 years off.

Re:Could be worse

[blackraven14250]

Oh, btw, it was deprecated in OpenGL 3.0 - 13 years off from being accurate.

Re:Could be worse

[Suiggy]

Yeah... I don't know what he's complaining about. iPhone OS uses OpenGL ES 1.1 and OpenGL ES 2.0. Of course you can't use immediate mode primitive drawing functions. In fact, you shouldn't be using them on the desktop either, if you're at all concerned about performance. Vertex buffers are the way to go.

Re:Could be worse

[Anonymous Coward]

Indeed you are right, LOL at glBegin !

Re:Could be worse

[Trepidity]

In fact, you shouldn't be using them on the desktop either, if you're at all concerned about performance

If you mean, are making an AAA game title, sure, but then your job is probably "3d graphics programming specialist" or something, so you can jump through whatever hoops are necessary. There's a huge range of apps for which performance is not really a concern; they ran fine on hardware of 10 years ago, so they ought to be able to run fine on today's. xDaliClock is one of those.

Re:Could be worse

[Anonymous Coward]

DirectX 2 was released in 1996. Which is kind of 15 years ago except it's only 14 and that it's DirectX but not OpenGL.

Re:Could be worse

[Trepidity]

Oh but don't worry, if you use the new enlightened way of doing OpenGL programming, you can write a "Hello World" app that fades between two images in:

380 lines of C and a couple dozen lines of shader code

Re:Could be worse

[zippthorne]

No, performance is *always* a concern on a battery powered device. Every single instruction has a cost in ergs. You don't want to waste them.

Re:Could be worse

[Skowronek]

The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.

A hardware implementation of IM (like the one in Silicon Graphics machines) would probably bring much higher energy efficiency than carefully packing up VBOs with software. Even when there's no hardware implementation, the packing up can be equally well performed by a driver, thus just shifting the energy consumption around, not increasing it.

Thus, immediate mode is actually at worst just as efficient as VBs for small vertex counts or dynamic objects, and at best allows hardware acceleration where there is none with VBs.

Re:Could be worse

[beelsebob]

The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.

No, no it's not.

Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.

Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it. After that point, all the CPU need to is yell at the graphics card "now render this".

The *reason* we've moved from immediate mode to vertex attribute arrays is because they're faster and more efficient. Of note, these days, even shader pipelines are more efficient than fixed function ones, because the fixed function pipeline is commonly implemented in the driver as a shader. A shader that is doing a bunch of stuff you don't need it to, along side the stuff you do want to happen.

Re:Could be worse

[Trepidity]

That I agree with, which is why I purposely quoted the part of his sentence including "on the desktop". On the desktop, the vast majority of OpenGL apps, i.e. anything except state-of-the-art AAA game, does not really need to squeeze that last bit of performance out.

Re:Could be worse

[PopeRatzo]

Can I take this opportunity to mention that I find programmer-fights fascinating?

Carry on, guys.

Re:Could be worse

[chill]

As a non-OpenGL programmer, help me out here.

Is that sarcasm or are you impressed? I'm having a hard time telling. 380 lines of C for "Hello World" is a tad much, but using OpenGL to fade between images...

Re:Could be worse

[moosesocks]

You missed the part where this is the Dali Clock. The iPhone needs to melt in order for the program to be completely functional.

Re:Could be worse

[Skowronek]

Entirely correct @ shaders.

However, I have to take exception with your description of immediate mode - the reason it performs so poorly now is that modern graphics chips are designed pretty much exclusively for DirectX (at least, this goes for ATI).

On machines where immediate mode performance was actually some kind of a priority (for instance, SGI Octane IMPACTSR and relatives), executing a glVertex command amounted to 3 memory writes into a command FIFO that was mapped into a fixed address in userspace which was accessible with a short form of a SW opcode (remember, this is MIPS, there is a range of 64k addresses that can be accessed without loading a base register: -32768 to 32767).

The hardware even managed the hiwater/lowater status of the fifo, and notified the kernel to perform a context switch to a non-gfx process when the gfx process was filling up the command FIFO. Those switches were as a matter of fact "virtualized" (before it was cool) by a combination of hardware, kernel (if hardware contexts are exceeded) and userspace - not entirely unlike what DX10 ADM was supposed to be, except this was in 1995.

For large static meshes (only transforms applied with Vertex Shaders), buffers are definitely going to perform better, because the meshes can be located in local memory (VRAM). However, if something is dynamically generated, immediate mode in a good implementation is no slower than a memcpy, and it does not require a kernel transition to submit a command buffer to card's ring (like modern cards like to do).

Re:Could be worse

[gman003]

Pretty sure that's sarcasm, since it would be a couple dozen lines with the deprecated stuff.

I don't get why the ARB does half the stuff it does. Why can't we have a default shader that does all the basic stuff we've been depending on for years?

Re:Could be worse

[rwa2]

Not much of an OpenGL programmer either, but I'm pretty sure that's sarcasm.

OTH, fading between images using compositing to allow that operation to be GPU-accelerated is a pretty legitimate use of OpenGL, though.

Re:Could be worse

[multi io]

Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.

Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it.

Unless I'm very much mistaken, vertex arrays (in client memory) is what the driver does internally to implement immediate mode anyway. I.e. all your glVertex etc. calls are collected in an array, which is sent to the GPU on glEnd(). So, if you just do all that yourself to avoid using immediate mode, you won't gain any performance. What IS faster is using vertex buffer objects, because they reside in graphics memory and thus DON'T "require a single upload of a constant array to graphics memory" -- which might otherwise become a major bottleneck if you're rendering the same geometry over and over again.

Re:Could be worse

[mdwh2]

Because it's not optimal for how graphics cards work these days. What would you prefer - an API that makes it clear what the optimal code path is, or a way that lets you save a few lines, but results in poorer performance?

And DirectX works exactly this way too, by the way, so it's not just OpenGL. The problem that OpenGL was having was that it was getting bogged down with legacy calls that these days are bad practice.

Your argument is basically a 3D version of the "But I can write Hello World in BASIC in much fewer lines than in C!"

Re:Could be worse

[Assmasher]

"His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!"

What?

glBegin() was deprecated as of OpenGL 3.0.

OpenGL 2.0 was released in September 2004 (5 years ago.)

If you meant OpenGL 1.1, that was 13 years ago, and glBegin() certainly wasn't deprecated.

Re:Could be worse

[SharpFang]

Tell me please, then, why did he have to use OpenGL in the first place? All he wanted was to display a bitmap on the screen. You'd think such basic functionality could be supported by the API on both platforms in a compatible manner...?

Re:Could be worse

[jabbathewocket]

This kind of thinking is what leads to decisions like "no multitasking for third party apps" .. There is plenty of horsepower so i can be lazy and write crappy outdated code and then blame the platform for not being "backward compatible/cross platform compatible" There is really nothing to see in this article/rant other than an angry person looking to find flaws in something because suddenly that is "the cool thing to do" I would like to remind him however that Apple has gone out of its way to make crossPlatform be a "bad idea" on iphone, they make no apologies for it, and actually have a really good reason for doing so .. Big deal

Re:Could be worse

[Trepidity]

But OpenGL immediate mode really is fast enough for a huge range of applications. It was fast enough twenty years ago, so surely it should be fast enough today also, unless someone graphics cards have magically gotten slower.

Re:Could be worse

[Anonymous Coward]

no shit, have two views (one for the old number, one for the new number), create an animation transaction, remove the old view, add the new view, and commit the transaction. That's it. If you need more control, you can use Core Animation (it might require 20 lines instead of 10).

Re:Could be worse

[Anonymous Coward]

// This creates a bitmap
CGContextRef CGBitmapContextCreate (
      void *data,
      size_t width,
      size_t height,
      size_t bitsPerComponent,
      size_t bytesPerRow,
      CGColorSpaceRef colorspace,
      CGBitmapInfo bitmapInfo
);

This creates an image from the bitmap.
CGImageRef CGBitmapContextCreateImage (
      CGContextRef c
);

This draws the image to the what ever context (ie: Screen, PDF, another bitmap, etc...) you want.
void CGContextDrawImage (
      CGContextRef c,
      CGRect rect,
      CGImageRef image
);

All three of these are on both the iPhone and Mac OS X

Re:Could be worse

[W2k]

Windows Mobile does not have a backwards/forwards compatibility problem with desktop Windows because both run .NET. The GUI parts are different in places but you don't want to re-use those anyways as a desktop UI looks and works like crap on a mobile device. For the most part, though - and certainly including such basic bits as color management - .NET on the desktop is a perfect superset of .NET Compact Framework on Windows Mobile. Furthermore, the docs neatly outline what is available in CF and what isn't. At one of my previous jobs we used to literally compile the exact same (non-GUI) C# code for Windows Mobile and Windows XP/Vista. Only very few #ifdefs were required.

Now that Microsoft is going with Windows Phone 7, where apps will apparently be entirely Silverlight-based, I am guessing compatibility will be even better. Imaging building a web/desktop app in Silverlight/WPF and then changing the compiler flags to make an app that runs locally on any Windows Phone 7. No #ifdefs in sight. Nobody else has anything close to that level of portability between desktop/mobile except maybe Adobe.

Re:Could be worse

[multi io]

(repost -- the first time I posted this, the article was visible only for me when I was logged in)

Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.

Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it.

Unless I'm very much mistaken, vertex arrays (in client memory) is what the driver does internally to implement immediate mode anyway. I.e. all your glVertex etc. calls are collected in an array, which is sent to the GPU on glEnd(). So, if you just do all that yourself to avoid using immediate mode, you won't gain any performance. What IS faster is using vertex buffer objects, because they reside in graphics memory and thus DON'T "require a single upload of a constant array to graphics memory" -- which might otherwise become a major bottleneck if you're rendering the same geometry over and over again.

Re:Could be worse

[Anonymous Coward]

So basically the author of the post was using old APIs, and got burned?

He was whining on about PICT data types! PICT!!!!

Re:Could be worse

[HickNinja]

Another problem is immediate mode vertex data is tied to the GPU front end vertex / data fetch rate, while vertex buffer data is read through the texture fetch path (much, much higher bandwidth). So the max rate for each type is fundamentally bottlenecked by the architecture, even if you could transfer it in at the same rate. The fixed function GPU front end is not as massively parallel as the general purpose shader engines / texture fetch portion. To reach the same levels of performance on immediate mode, the architecture would have to change significantly, and it would most likely come with a large area hit, which directly translates into chip yield / cost.

Re:Could be worse

[CharlyFoxtrot]

I found this quote from jwz's reply to one of the comments telling :

"Part of the problem with being spoiled for choice is nowhere is there documentation -- that I would have dearly loved to find when I was just starting to learn this stuff -- that says things like, "look, you really don't want to use anything beginning with NS, just use the CG ones, that's the maximally-compatible way." It's damned near impossible to even find statements like, "CG-based stuff will work on 10.3-present, and CG is officially not-yet-deprecated so you've got a least a few more releases before you'll be expected to rewrite it all.""

So basically he implemented things a certain way a couple of years ago and later when he wanted to reuse the code for what's basically another platform he found out that by doing it that way he fucked himself. Then he does what we all do: get mad at the gun for allowing us to shoot ourselves in the foot; "if only there'd been some documentation AND I had read it AND had been smart enough to follow the recommendations". Earth shattering, clearly. The only way this is news is because it contains the magic words Apple and iPad.

Re:Could be worse

[beelsebob]

Every single thing in the documentation is associated with an implicit "this will be the same in at least the next two major releases of OS X", unless it has an explicit "this was deprecated in version xyz of OS X".

So far, I don't know of a single API that has been removed from Mac OS, although a lot have been deprecated since 10.0.

In general though, you're right. Expecting your code to "just work" on a brand new platform is moronic. Especially a platform as different as iPhone OS is. To be honest, most likely he's seen that there *is* a lot in common between the Mac OS and iPhone OS, and assumed they must be almost exactly the same.

Re:Could be worse

[Skowronek]

Actually, there are several operations that make the vertex fetch operation less parallel than you might think. In particular, vertex sharing by multiple primitives is usually handled with a small depth (32-64 vertices) buffer. In other words, if a vertex index occurs twice in your object, but those occurences are >128 locations apart in your index buffer, the vertex will be processed twice and you won't get peak performance. Another example is the primitive assembly stage, when processed vertices that are output from the Vertex Shader are merged into primitives according to the data in the index buffer. This is a significant performance bottleneck that makes VBO bandwidth lower than fragment shaders.

The assumption that improvement of immediate mode performance would necessarily come with a large area hit is not supported. Most of the GPU area is not control units (which this would end up being, since the datapaths are already in place); it's the memory controller, raster backends and shaders. A quick look at the floorplan of a modern (>2008) GPU proves this quite readily. Even the primitive assembly / triangle setup unit usually occupies less than 2% of the GPU, and it is the current VS rate bottleneck.

Re:Could be worse

[MostAwesomeDude]

It's also about command space. Say you have 64k per command buffer, and flushes are ungodly expensive. Now say that immediate-mode verts need to get placed directly in the command buffer, and VBO renders cost roughly 50 dwords per 16m verts. A wise maths person might conjecture that the maximum number of verts one might expect to submit quickly in immediate mode is about 10, yes?

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_render.c#n141

Re:Could be worse

[gman003]

The thing is, much of the time you don't need to write a custom shader. Usually, you just want the same processing done that's been done for ages.

The argument is more akin to "why do I have to do a bunch of syscalls to set white text, black background, for my Hello World, instead of just letting the default of white text, black background be loaded automatically?"

Especially since quite a bit of legacy hardware doesn't support shaders period!

Re:Could be worse

[Alamais]

It's even better if you imagine they're both wearing monocles.

Re:Could be worse

[Anonymous Coward]

and they don't claim cross platform comparability either.

Re:Could be worse

[Maniacal]

Man, me too. I always read through them and I don't know what the hell they're talking about most of the time. What is it with that? Maybe I find it fascinating that these arguments happen at all. I mean, you would think that, aside from emerging technologies, the best practices for everything has already been worked out. I guess it's silly to think that but maybe I just thought there would be less to argue about. It seems as if every point a person makes is contradicted. Is there a zen superhacker who knows all and we can just ask him? Maybe Hugh Jackman?

Re:Could be worse

[zippthorne]

Wait.. are you seriously suggesting that Apple change the hardware of their devices to fit the way you think the software should work??

Re:Could be worse

[Skowronek]

No, but there's this argument going around that "immediate mode necessarily performs worse" which is simply not true, if your hardware is not constrained. My view comes from spending a good few years designing GPU chips - we could do whatever we wanted as long as there was enough demand for it.

There isn't enough demand for immediate mode, and for OpenGL in general. That doesn't mean it's not possible to make it perform well.

Additionally, Apple likes to make their own hardware (just look at their recent ex-ATI employee acquisitions) so they can do whatever they please with their chips. Especially in portables.

Re:Could be worse

[Skowronek]

I did not mention command buffers as a way to submit IM operations; I agree with you entirely that it would result in very sub-par performance.

Some machines, generally older than the R300 or in fact any of the consumer hardware (the ones that OpenGL came from), were optimized for IM and executed it through direct MMIO writes from userland. This avoids the problem of both command buffer size limitations and the high price of ioctl-style command buffer submits.

Re:Could be worse

[Anonymous Coward]

Correction:

Directx and Opengl

Consistency, my dear. If it's Iphone because proper nouns always begin with a capital letter and have no other capital letters, then follow your own rules.

Re:Could be worse

[mdwh2]

GL is short for Graphics Library. It's what we call an abbreviation.

DirectX or Directx; IPhone or Iphone - both are fine, and I don't really care between them. But both are proper nouns, and the first letter of proper nouns in English is capitalised. Not that I even said "Iphone" in my post, so I guess I've got some sad stalker.

I don't follow my own rules, I follow the rules of basic English. Nowhere have I claimed that proper nouns "have no other capital letters", so you can take your straw man elsewhere.

Re:Could be worse

[mdwh2]

But as I say, that argument applies to DirectX at least as much as OpenGL.

And sure, the latest versions of OpenGL and DirectX won't be suited to almost decade old hardware ... I'm not sure that's really a problem though.

Re:Could be worse

[Anonymous Coward]

GL is short for Graphics Library. It's what we call an abbreviation.

The rules of English don't allow for abbreviations mid-word.

DirectX or Directx; IPhone or Iphone - both are fine, and I don't really care between them.

But you do. You write DirectX consistently, because oddly enough, you know its name. The rules of English permit capital letters only at the beginning of words or in proper names, which are written as officially named.

But both are proper nouns, and the first letter of proper nouns in English is capitalised.

No. Proper nouns are usually capitalized. Proper names are always written in their official form. MacAllister is an invalid English word, but it's a proper name, so it is written 'MacAllister'. When you see "de Haviland" you write it exactly like that, because it's a proper name. It's not 'De Haviland' The official name in English of the Netherlands is 'the Netherlands' and not "The Netherlands".

I don't follow my own rules, I follow the rules of basic English

No you don't. You follow your made-up rules and apply them exclusively to products from a single source, in some sad act of derision no more tolerable than asshats who write M$.

Nowhere have I claimed that proper nouns "have no other capital letters",

You claim to follow the rules of basic English. Basic English designates a single place for capital letters: position one in the word. Basic English requires that words be separated by spaces. OpenGL, which you have no problem writing, violates this rule. It must be Open GL. But you don't write that, because you're stupid, but you're not stupid.

you can take your straw man elsewhere.

The only straw man is that proper usage of English ever requires an intentional misspelling of a formal name.

Man

[arcite]

What a whiner.

Ubuntu

[Anonymous Coward]

Of course we're still innovating!

All innovation is good! It's never a waste of time! Ever!

Ask Ubuntu!

UIKit != AppKit

[Anonymous Coward]

The OS is the same, but UIKit is NOT the AppKit. It's like bitching against linux when trying to build your Qt code against gtk.

Re:UIKit != AppKit

[phantomfive]

He does have a point though, and I have also felt that while UIKit gets the important things right, it feels a little rushed around the edges. And it was rushed, so that's not surprising.

His example there is pretty clear, instead of using the perfectly good class NSColor, they rewrote it differently as UIColor, leaving some important functionality out. You can deal with it, sure, but it's kind of annoying.

Still, I don't know who was expecting any sort of compatibility on the GUI portion of the iPhone, since the paradigm is completely different. It doesn't even make sense to think that you wouldn't have to rewrite the front end. On the other hand, I haven't found any problem porting C code or C++ code to the iPhone; I don't claim to be an expert but it does use GCC. In other words, it is highly compatible with existing code, but you'll have to rewrite your user interface. Which is probably what you were planning on doing anyway.

Re:UIKit != AppKit

[Linker3000]

Meh - the fix to get the Dali clock working is trivial - rename all pointers to smell like the colour yellow, and change all LONGINTs to SURREALs.

Re:UIKit != AppKit

[Chris Mattern]

It's like bitching against linux when trying to build your Qt code against gtk.

It's like bitching against something billing itself as "Linux desktop compatible" when your Qt code isn't supported on it, only gtk. Which would be a legitimate gripe; "Linux desktop compatible" should support Qt as well as gtk.

Re:UIKit != AppKit

[Sir_Lewk]

it is highly compatible with existing code... ...but you'll have to rewrite...

*head kersplode*

Re:UIKit != AppKit

[guruevi]

It should also support native X11, Blackbox, Enlightenment, perlwm, PLWM and WindowMaker.

Re:UIKit != AppKit

[psavo]

I just looked up it from the clock, and the year seems to be 2010 and these fuckers are still making the same mistakes that Symbian did in 1995. They still think about mobiles like they'll always be different from desktops. Well guess what, they have nearly same capasity now that desktops have and *most* of their capabilities are in the same ballpark. But *noooooo* the fucktards need to have their own unique type of a fucking color.

Fuck you, symbian & iphonetardos designers.

Re:UIKit != AppKit

[Assmasher]

Thank you for that :). I was having a shitty day - it's a little bit better now.

Re:UIKit != AppKit

[SharpFang]

Not necessarily directly, but it should not ban the users or developers from installing these if they wish so.

OTOH, it could just claim it's Linux Gnome and GTK compatible.

Re:UIKit != AppKit

[ciaohound]

The only difference between you and a madman is that you are not mad.

Re:UIKit != AppKit

[SharpFang]

sed /NS/UI/
sed /(\w+?).isOK()/!$1.isNotOK()/
sed /getRed()/getColor("Red")/
sed /onClick/onTap/
sed /toRGBA(r,g,b,a)/toRGB(r,g,b).setAlpha(a)/ ...and the like.

(nope, not serious)

Re:UIKit != AppKit

[jabbathewocket]

Nearly the same computing capacity yes.. but with terrifically small screen resolutions and battery life to deal with. Even if i could get a quad core 3+ghz cpu, 16 gigs of RAM, 2 terryabtes of storage, and 50megabits per second of network speed, as well as whatever the best performing GPU on the planet is at the time of release.. We are still limited by the physical reality that you cannot jam any more juice into a battery that has to fit in a mobile device.. nor can you somehow "shrink" a UI from a 20-27" desktop screen, onto a mobile device.. they are just impossibilities Since the mobile needs to have a very different UI, it makes sense that the "UI" layer of the APIs will vary .. And no amount of crying will change that fact, and no amount of worshipping to the Flash Gods at Adobe is gonna get you your wish either.. You want to do multiplatform correctly you have to embrace each platform with all its quirks and idiosyncrasy's intact,,

Re:UIKit != AppKit

[tepples]

They still think about mobiles like they'll always be different from desktops. Well guess what, they have nearly same capasity now that desktops have and *most* of their capabilities are in the same ballpark.

Let me know when you can efficiently write code or a novel on an iPhone-sized device. Input and output are device capabilities.

But *noooooo* the fucktards need to have their own unique type of a fucking color.

Colors restricted to the output device's color space (UIColor) are a different type from colors in an arbitrary color space (NSColor).

Re:UIKit != AppKit

[nine-times]

Even if legitimate, wouldn't it be a little iffy? You say:

"Linux desktop compatible" should support Qt as well as gtk.

But according to who? You could have a Linux desktop distribution that didn't support Qt.

Re:UIKit != AppKit

[Leynos]

Model Controller View.

The existing code being the model (and bits of the controller, I'd imagine).

Re:UIKit != AppKit

[Anonymous Coward]

Learn to structure your code right and then you'll understand.

Re:UIKit != AppKit

[Anonymous Coward]

The reason things like NSColor were changed in the iPhone OS is because the Mac OS has a lot of legacy code for things like ColorSync, where the OS had to support many different monitors and color profiles. Instead of carrying all that cruft forward, it was stripped out.

Re:UIKit != AppKit

[Anonymous Coward]

highly, not completely. kids these days and their heads exploding... on second thought, that's great way to teach reading comprehension.

Re:UIKit != AppKit

[Anonymous Coward]

it is highly compatible with existing code ... but you'll have to rewrite your user interface

Wow, if you add the context back in it suddenly makes sense!

Re:UIKit != AppKit

[Gilmoure]

If Linux Corp. says it should support both, then it should support both. This is a major corporate operating system. It's not like just anyone can go and put together a Linux distribution. Linux Corp. wouldn't allow that. There would be law suits and drive by shootings and such.

Re:UIKit != AppKit

[Matt Perry]

Thank you for that :). I was having a shitty day

With a user name of "Assmasher" I would expect nothing less than a shitty day.

We get it already

[kickme_hax0r]

People don't like developing for the iP[whatever]. I suppose we'll be seeing a new article every time someone somewhere complains about it.

Re:We get it already

[beelsebob]

I think the point is more, people *do* like developing for the iP[whatever]. There is however a vocal minority which happens to hit a note with people on Slashdot, who don't like that people like developing for iP[whatever]s.

Re:We get it already

[FuckingNickName]

No. People like making money with the iPhone. But development in the classical sense, i.e. "growth; progress", does not occur on iPhone.

Re:We get it already

[phantomfive]

I think the GP is right, I for one at least really enjoy programming for the iPhone. Core Animation is a thing of beauty. If you haven't seen it, you should check it out. Objective-C is what C++ could have been if they had done it right. The default GUI elements make it easy to create decent looking apps. Overall, if you ignore the DRM, programming for the iPhone is quite nice.

Re:We get it already

[FuckingNickName]

Objective-C is what C++ could have been if they had done it right.

No, there is no real way of objectifying C well, because C is essentially a low level systems and high performance macro assembler, designed for people who want to and need to care about the underlying system. Now, C# is a fairly good language with C-type constructs,and Java is ok-ish, but they are managed languages more abstracted from the underlying hardware.

Objective C is an attempt to mix macro assembler with the beautifully pure OO language that is Smalltalk, giving the advantages of neither.

I did like Objective C when I first learnt about it, about 16 years ago. I was a teen and my knowledge of languages extended little beyond BASIC, C, C++, Forth and a vague understanding of LISP. I craved something fit for a more high level purpose. Objective C is an experimental half way house which has been hanging around because C++ is so bad and Jobs happened to run NeXT, but it's no pleasure.

Re:We get it already

[bostei2008]

Objective-C is what C++ could have been if they had done it right.

You are kidding, right?

Re:We get it already

[Nerdfest]

RDF exposure ... give the man a break.

Re:We get it already

[ThePhilips]

Objective-C is what C++ could have been if they had done it right.

ObjC and C++ have totally different design goals.

For some applications I would prefer C++, for others ObjC. They do not compete against each other, but rather complement.

Why in the end the Objective-C++ was actually born: to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.

Re:We get it already

[FuckingNickName]

Why in the end the Objective-C++ was actually born:

"Just because you shouldn't, it doesn't mean you can't."

to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.

With the utmost respect, anyone who fails to recognise the very basic difference between `loose' and `lose' is unlikely to have a proper appreciation of when (or indeed whether) weak or strong typing is needed. As for "messaging", well, just because Objective C calls it a message and C++ calls it a polymorphic method call, it doesn't mean there's a relevant difference.

Re:We get it already

[MikeFM]

I don't find Obj-C any worse than Java really. I do wish it had a more extensive lib of useful classes but that isn't really a failure of the language. The biggest annoyance to me has been the mojo around doing things the Obj-C way. Rather than giving good feedback on your code functionality Obj-C fans just go on about how your coding style isn't the one true way. Of course Java fans can't explain why Java has problems with basic OOP functionality other than saying that you can't do that in Java. Fun.

I think most Obj-C books suck though. Don't believe that they'll have you coding iPhone apps in a week. Even as an experienced programmer it took me longer than that to get familiar with Obj-C and learning Cocoa and Touch is more involved than they tell you. XCode is okay but stay away from their crappy Interface Builder as it's a complete waste of time.

Re:We get it already

[Anonymous Coward]

Objective-C is the World's Worst Programming Language. Even Wikipedia says so! (Well, at least until someone revises my edit.) It is nothing like C++, where the compiler is capable of catching all sorts of problems.

It's also VERY slow.

Re:We get it already

[HuguesT]

The difference is very relevant. I don't think there is a nice way to pack the kind of information that exists in a NIB file using C++ as a development language. Certainly none of the Microsoft, Gnome or KDE designers have done it. You basically have to specify all the callbacks by hand somehow in the interface file in C++, and compile the interface in. Compare this with the NIB+objective C way. The NIB file contains your whole interface, you can change almost everything about the appearance of your application, and you don't have to recompile at all.

So in theory you are right, in practice, objective-C works well in its context, better than C++.

Re:We get it already

[kmike]

Steve, is that you?..

Re:We get it already

[ThePhilips]

As for "messaging", well, just because Objective C calls it a message and C++ calls it a polymorphic method call, it doesn't mean there's a relevant difference.

You apparently never tried to implement the message passing in general or in C++ in particular. I unfortunately did.

It all boils down to the trivial problem: given an object, one should be able to call a random method on it.

C++ forbids this due to strict typing and compile time binding. Nor you can't represent a method as a variable. Nor implementing hundred/thousands of abstract classes is practical or sane.

Objective-C has that as a feature. Selector is a basic data type.

You can queue up selector/object pairs in ObjC for later calling - you can't anything close to it in C++. Thus no native messaging in C++.

P.S. One can implement that also in C++ - see all the insanities TrollTech had to go into to do it in Qt. They use strings to identify methods during compile time, create class vs. method tables during link time and during run-time perform look-up on the table to identify the method's entry point.

P.P.S. loosing v. losing. Give me a break, man. It's Monday. I obviously meant "losing".

Re:We get it already

[FuckingNickName]

What on earth has the availability of an interface builder app got to do with language function call semantics / implementation differences?

Are you trying to imply that something about C++ means that I have to recompile backend.cpp when I change the implementation detail of called routines in gui.cpp, even when the interface remains the same? Because no.

Re:We get it already

[mdwh2]

Well, we get three stories a day, everytime someone says they do like something about the Iphone/pad, so fair's fair.

Re:We get it already

[b4dc0d3r]

With the utmost respect, anyone who fails to recognize the very basic difference between having a unique online personality instead of typing "FuckingNickName" because they could not be arsed to come up with something unique is unlikely to have a clue or valued opinion about anything, at all, ever.

Or we could proceed the usual way where I don't know your name and I evaluate your ideas instead on their merit, and you don't know other peoples' typos because we're speaking to each other. Civilly. Like grown ups.

Re:We get it already

[CharlyFoxtrot]

Rather than giving good feedback on your code functionality Obj-C fans just go on about how your coding style isn't the one true way.

This is true. I've found that programming for the iPhone a lot revolves around following convention and best practices. I kind of like it, maybe because I'm not that experienced a programmer, it provides a guide.

Don't believe that they'll have you coding iPhone apps in a week. Even as an experienced programmer it took me longer than that to get familiar with Obj-C and learning Cocoa and Touch is more involved than they tell you. XCode is okay but stay away from their crappy Interface Builder as it's a complete waste of time.

Check out the free Stanford course on iTunesU (videos available through iTunes). It's probably the best resource out there if you've already got the necessary background (some C and OOP and design pattern knowledge). You won't be doing The Next Big Thing in under a week, but you can be creating simple demonstration apps in that time.

Re:We get it already

[FuckingNickName]

It all boils down to the trivial problem: given an object, one should be able to call a random method on it.

C++ forbids this

What you might mean is, "I can't build up a random method call at runtime in an ANSI standard way". Your "trivial problem" is soluble at compile time, as is the intention for statically typed languages.

Nor you can't represent a method as a variable.

However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers). You probably want to use an pointer of abstract base class type, i.e. interface. Why do you keep wanting to defeat static typing?

You can queue up selector/object pairs in ObjC for later calling - you can't anything close to it in C++. Thus no native messaging in C++.

I don't define messaging as "queueing up a random sequence of method calls chosen at runtime for later calling". Again, you're probably looking for some array type from which elements are consumed to call methods (perhaps chosen using member function pointers) via a pointer typed to an abstract base class.

If you want to be able to queue random calls to /anything/, represented in some language-defined way as calls with all their parameters, just because it's nice to say you can, you are probably looking for a completely dynamically typed language like Smalltalk.

Re:We get it already

[FuckingNickName]

OK, b4dc0d3r, we get it, it's tough in this post-'90s world to find someone with a less hip nick. I spent about 8 years posting AC on /., but it was tiresome to hear people like you complaining about my lack of identity.

FWIW, calling "loosing" a typo is like calling "nigger" a slip of the tongue - there's enough case history to reveal that it reflects an error in the CPU, not a transient fault at the output device.

Re:We get it already

[oiron]

You could also use SigC++ or Boost.Bind, or even std::mem_fun in modern C++...

Re:We get it already

[ThePhilips]

However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers).

Method pointers are bound to a class.

That means code need to know explicitly the interface to call a method.

You probably want to use an pointer of abstract base class type, i.e. interface.

When you get a pointer to the object of a base class, you can't upgrade it inside of the message dispatch - because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program. And that's simply impractical, most of the time impossible.

Why do you keep wanting to defeat static typing?

I'm not.

It was you who tried to indicate that the messaging is somehow implementable with polymorphism. And it is not. As you yourself point out between the lines: it is simply incompatible with static typing.

If you want to be able to queue random calls to /anything/, represented in some language-defined way as calls with all their parameters [...]

That what messaging often boils down to.

Constantly serializing/deserializing is way too expensive.

[...] you are probably looking for a completely dynamically typed language like Smalltalk.

... of which the Objective C is one of the descendants.

The End.

P.S. I have tried to implement messaging in C++ at least twice. Once by serializing the calls, second time by trying to have interfaces for all used methods. First failed due to miserable performance. Second failed when more people were assigned to the project and it became impossible to maintain -in any sane fashion- list of used interfaces and dispatch code was constantly broken due to changes to the other parts of the software.

Re:We get it already

[ThePhilips]

Thanks!

SigC++ looks interesting.

From the examples, it seems that Boost.Bind is something slightly different and more of STL's bind extension.

Re:We get it already

[discord5]

Objective-C is what C++ could have been if they had done it right.

Oh God, don't... just... DON'T! I've seen this type of argument before, and the conversation that unfolded before my very eyes was a disaster. Had it been held on a forum, usenet or anything remotely related to internet it would have been called the flamewar of all times. We even had a guy trolling both camps, and all the discussion achieved was that both sides agreed that they disagreed.

Personally though, from what little experience I have with the language, I really dislike the way Objective-C code looks. The whole [ ] thing for calling methods looks unsightly and out of place.

Cat* aCat = [ [ Cat alloc ] init ];

just doesn't have the same elegance that

Cat * aCat = new Cat();

has to me. The whole [ ] syntax just gets on my nerves. Now, having said that, there's lots of things in C++ that gets on my nerves as well, but nothing quite as early on into the language as calling a method. I guess once you get used to it things 'll get better.

Re:We get it already

[FuckingNickName]

That means code need to know explicitly the interface to call a method.

What problem are you trying to solve where you don't know the format of any messages you need to send?

because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program.

Eh? A static number for interface, a static number for function, a two-level lookup table.

Constantly serializing/deserializing is way too expensive.

What's a Selector object doing, behind the scenes?

... of which the Objective C is one of the descendants. The End.

No, it's the bastard offspring of C and parts of the Smalltalk platform. Smalltalk implements everything using messages to objects, whereas Objective C does sometimes. I can't just break open the inspector at runtime and edit an Objective C app, i.e. list of messages and nothing but, on the fly. Hell, until a couple of years ago I still had to worry about tracking memory allocation!

Re:We get it already

[Megane]

so... tl;dr: Objective C merely sucks less?

I can agree with that.

(I'm still annoyed about what Borland did to Object Pascal, for what it's worth.)

Re:We get it already

[klipsch_gmx]

P.S. One can implement that also in C++ - see all the insanities TrollTech had to go into to do it in Qt. They use strings to identify methods during compile time, create class vs. method tables during link time and during run-time perform look-up on the table to identify the method's entry point.

What you're essentially talking about is reflection. Reflection is slow as balls. C++ is not slow as balls. Get it?

Re:We get it already

[ThePhilips]

What's a Selector object doing, behind the scenes?

Selector is essentially a pointer to a method. It doesn't serialize a damn thing. Unlike C++ method pointer, it is not bound to a class - you can apply a selector to any object. And you obviously always can find whether the object responds to a particular selector or not.

Eh? A static number for interface, a static number for function, a two-level lookup table.

Eh? "Static number for interface"?? "Static number for function"???

Go back to the kindergarten.

Re:We get it already

[Anonymous Coward]

I can't just break open the inspector at runtime and edit an Objective C app, i.e. list of messages and nothing but, on the fly.

Actually, you can do precisely that. You can even create entirely new classes at run time, or extend existing classes by adding new methods to them.

Hell, until a couple of years ago I still had to worry about tracking memory allocation!

If clicking on a menu item to generate accessor methods causes you to worry, then you have a lot to learn.

Re:We get it already

[FuckingNickName]

Selector is essentially a pointer to a method. It doesn't serialize a damn thing

When implementing polymorphism, or message passing, or whatever you like to call it, you are turning a list of words, i.e. the selector, into some sort of unique identifier or hash or offset into a lookup table or who cares what. That's all your "damn" selector is. You are augmenting that with list of arguments which you somehow queue. Your machine is serialising the abstract notion of "passing a queue of messages" into numeric representation of method plus list of arguments, which are built up again to form an actual procedure call, no matter how fancily your Apple documentation likes to describe it.

Eh? "Static number for interface"?? "Static number for function"???

Sigh. Any interface in the world is assigned a single unique unchanging number (OK, C++ just uses the name, but it comes to the same thing within a single organisation). Any method of that interface is denoted by an single unique unchanging offset into some table. If you can ask an arbitrary object for "method 56 of interface 11", your problem is sorted. What is so difficult about your dispatcher being able to make such a lookup?

Go back to the kindergarten.

Why does every argument with an Apple fanboy end up with some comment like this? You've spent about half a dozen messages arguing that C++ doesn't support "messages" just because it doesn't support messages precisely as you want them to, and because you refuse to invent or use one of half a dozen implementations which allow you to use C++ as you want it to. I've pointed out that you're spending way too long complicating what an interface actually is, and you end up by telling me to go back to the kindergarten.

You're either a troll or in the frame of mind which resulted in the "loose" typo right at the start of this thread...

Re:We get it already

[shutdown -p now]

Objective-C is what C++ could have been if they had done it right.

To paraphrase the classics, Obj-C is a language that has all the readability of C combined with all the performance of Smalltalk.

As for C++ - it is an abomination in its own right, sure. But at least it does bring something to the table which no-one else offers so far - statically typed generic programming that's as fast as manually written code.

Re:We get it already

[Space cowboy]

The syntax is different, but using a language is only ~5% syntax, the rest is how it all fits together. I far prefer how ObjC fits together than C++, ObjC seems ... elegant, whereas C++ feels more like the kitchen sink actually *did* make the trip, along with the rest of the house, neighbourhood, and probably universe. All packed up into a computer language.

And, it's not *that* different on the surface.... Compare:

Cat *cat = new Cat();

... to ...

Cat *cat = [Cat new];

I've just been writing some plugin-management code. Because of the dynamic nature of the language, it took about 20 minutes to write ~40 lines of code that loads, validates as conforming to a protocol, initialises, and registers bundles of code at run-time. My C++ has become rusty since I switched to ObjC, but I think it'd be harder than in ObjC...

Simon..

Re:We get it already

[ThePhilips]

Why does every argument with an Apple fanboy end up with some comment like this?

I'm very very far from being anything like an Apple fanboy.

Neither I'm a huge fan of ObjC. Strict typing of C++ is better suited for the types of applications I write (and kind of mistakes I usually make - love the compiler finding the errors for me).

I have simply tried to correct where you were wrong.

But it does seem you lack practical experience to even understand the problems ObjC was introduced to solve.

Any interface in the world is assigned a single unique unchanging number [...]

If you can ask an arbitrary object for "method 56 of interface 11", your problem is sorted.

Well, you really do lack experience to understand all the practical problems that causes (e.g. branching, collaboration), why in some scenarios it is not possible at all (e.g. plugins/dynamic linking) and why it is pretty much never used (waiting days for release to become compilable while people resolve the merge conflicts of the "unchanging number" lists).

And apparently I'm simply incapable of explaining that to you.

You should try to implement what you suggest in a commercial project with team 5+ people: you would understand the problems within few months down the development road.

You're either a troll or in the frame of mind which resulted in the "loose" typo right at the start of this thread...

Hehe. Payback for being a grammar nazi :D

Re:We get it already

[FuckingNickName]

Well, you really do lack experience to understand

That's the second popular argument from the Apple fanboys (I know you've denied being one, but you're acting like one) - "you wouldn't understand" what people need "in the real world".

all the practical problems that causes (e.g. branching, collaboration),

There are no practical problems if you have some damn discipline, and have learnt from Software Engineering 101 that you should write what you mean and let your preprocessor turn that into suitable code to maintain whatever standards you implement in your organisation. For example, Microsoft platforms have for a good 15 years gone straight for GUIDs for identifying objects, and it looks like Microsoft are doing OK.

why in some scenarios it is not possible at all (e.g. plugins/dynamic linking)

Sorry, what? I've just brought up some of my old code for a basic system monitor to run on bare hardware which handles the interface for drivers and other plugins via such a scheme. Some cunning stub/shim/whatever-you-like-to-call-it generation means transparent RPC, so the keyboard driver could be running on the local machine or across the world.

and why it is pretty much never used (waiting days for release to become compilable while people resolve the merge conflicts of the "unchanging number" lists).

You might as well argue that it's impossible to generate any stable API ever because developers will keep changing the names of their functions and the order of arguments.

Except they can.

And you can automatically generate a hash from number, type and order of arguments. And then store that for a reusable interface. Or whatever. Seriously, what happened to discipline in engineering? Read /The Pragmatic Programmer/, or something.

Re:We get it already

[FuckingNickName]

Actually, you can do precisely that. You can even create entirely new classes at run time, or extend existing classes by adding new methods to them.

I should have been clearer. I can't just break open the inspector at runtime and edit an Objective C app, i.e. list of messages and nothing but, on the fly. All you're describing is the ability in OS X 20 years later to do the much harder task of source level debugging and partial recompilation of apps under development for which you have the source.

But that is fairly good, I must admit.

If clicking on a menu item to generate accessor methods causes you to worry, then you have a lot to learn.

Wow, Visual BASIC flashback. You deal with garbage collection in pre-Leopard ObjC by "a menu item to generate accessor methods", now? How do all these supposedly world-changing Apple apps get developed when... oh, I give up.

Re:We get it already

[scribblej]

When you get a pointer to the object of a base class, you can't upgrade it inside of the message dispatch - because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program. And that's simply impractical, most of the time impossible.

I know I'm a moron, but... why would you do that? You implement the type-specific behaviour in the derived types, and then just call the inherited function on the base (say, 'recievemessage'), that's what polymorphism is fundamentally about... isn't it?

Re:We get it already

[Falconhell]

Pot>kettle.

Gee these prgrammer types have really bitchy fights.

Pity its all goobledegook to me!

Re:We get it already

[phantomfive]

I did like Objective C when I first learnt about it, about 16 years ago. I was a teen and my knowledge of languages extended little beyond BASIC, C, C++, Forth and a vague understanding of LISP. I craved something fit for a more high level purpose.

In other words, you tried out Objective C at a time when you were still inexperienced with programming languages. I only point this out because from your comment it is clear that you still have no understanding of programming languages, and have merely swallowed the view that Microsoft pushed onto you. Are you aware that 'managed code' is nothing but a Microsoft term, meaning essentially that it's running on a virtual machine? There is nothing magical about it that makes it inherently different than a compiled language, since basically any language could be 'managed' if you wanted it to be.

You don't even seem to understand the advantages of runtime type binding, which is one of the main benefits of Objective-C over some other languages. Your understanding of programming languages is nothing more than a bunch of cliches, at least that's how you present yourself. What a waste.

Re:We get it already

[FuckingNickName]

You're not a moron. We need to understand the scenario to be able to understand why, uniquely, every solution offered is inadequate. It wasn't forthcoming.

Re:We get it already

[mzs]

Except that it isn't as fast. Every time I look at what g++ did with objdump I see extra copies all over the place and code for dealing with a potential exception added. You really have to be a guru of C++ to avoid all the extra copying that happens and put the nothrows where needed. The reason I looked is someone compiled some C code to C++ to get the function overloading and then added just a smidgen of C++ism to the code (do it the C++ way not the C way he thought). Then our benchmarks were suddenly 5% slower.

Re:We get it already

[shutdown -p now]

Do the same thing you do in C, then - use pointers explicitly. C++ won't do copies unless you tell it to (and, yes, temporaries also count as "telling it to", because there are well-defined rules for them).

Alternatively, start using C++0x rvalue references (&&) already to get that move semantics.

#ifdef APPLE_HARDWARE

[syousef]

#ifdef APPLE_HARDWARE
      doItTheirWayOrHitTheRoad();
#endif

You complaining about a company that retains control of whether or not you can release the app to the device even if it conforms perfectly to their APIs. If that's not a deal breaker for you why do you think that complaining about shitty incompatible frameworks or passing colour components on slightly different programs is going to worry them? You're wasting your breath.

Re:#ifdef APPLE_HARDWARE

[10101001 10101001]

You complaining about a company that retains control of whether or not you can release the app to the device even if it conforms perfectly to their APIs.

Um, not quite. The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device (either by buying the app through an app store or paying a set fee to the company). This isn't too far off from the XBox 360, either. To some extent, it's not that far off from most any commercial library/OS (the main difference is whether you effectively pay the fee upfront or whether they try to nickel and dime you later).

If that's not a deal breaker for you why do you think that complaining about shitty incompatible frameworks or passing colour components on slightly different programs is going to worry them?

Apparently the Dali Clock is a rather old program (nearly 20 years) that's been ported to a variety of platforms. Presumably, the author chose to port the Dali Clock to the iPhone precisely because it was supposed to be relatively trivial to port from a Mac OS X version. The blog highlights how untrue that ended up being; comments on the blog suggest it's because Apple provided multiple graphical APIs and if the author had been lucky several years ago, he would have chosen the one that worked on the iPhone.

In short, it doesn't sound like the author bought his iPhone to write apps for it. It was more a porting exercise to see just how trivial the task would be.

You're wasting your breath.

No doubt. But, then, most blogs are a "[waste of breathe]". These comments, both yours and mine, would likely qualify as well. I don't think that'll stop me from commenting or considering the blog for what it is, a recognition of Apple having the same sort of failings that Microsoft does: designing too many APIs/interfaces/file formats, dropping support for them whenever they can, and generally being about as bad as any other platform when it comes to having a unified, solid solution to the many problems that exist for the developers. I will give Microsoft some credit, though, for generally waiting longer than most public, commercial software companies in maintaining strict backwards compatibility.

Re:#ifdef APPLE_HARDWARE

[Anonymous Coward]

"I will give Microsoft some credit, though, for generally waiting longer than most public, commercial software companies in maintaining strict backwards compatibility."

I no longer program, I moved on to a field where computers are ancillary to my line of work and happy about the reboot, but I remember this being the case even a few years back. Microsoft maintains strict backwards compatibility at all risks.

And this is the big difference between Microsoft and Apple. Microsoft cares more for their developers and the companies that make money off of them than they do their users. Apple cares more about the users than they do about the developers.

Microsoft has routinely left in holes in their OS that can't be easily fixed because a major software developer can't be bothered to fix their software.

Apple, on the other hand, I've seen them send out pretty terse notes to their major developers letting them know that if they don't change their use of an unexposed API (one they found has a hole it in...generally why Apple doesn't doesn't publish APIs until it is ready because they want to make certain it is ready for public...and apparently it applies to the iPhone as well)...and Apple will specifically tell major software houses that if their software isn't fixed in 30 days, it will cease working for anyone that updates their computer.

That said, I don't really care for Apple's walled garden approach to the iPhone and for those of us nerds, it is a major problem (I've had to jailbreak just for simple things like Googlevoice front ends...or tethering)...for the average user? not a problem. The point is, Apple cares far more for the user than the developer. Microsoft doesn't give a fuck about the user so long as the developers are happy.

So give credit to Microsoft for maintaining backwards compatibility, but you are just thanking them for providing a buggy OS that allows viruses to run rampant.

Re:#ifdef APPLE_HARDWARE

[10101001 10101001]

I no longer program, I moved on to a field where computers are ancillary to my line of work and happy about the reboot, but I remember this being the case even a few years back. Microsoft maintains strict backwards compatibility at all risks.

DOS games on WinNT. Win16 on Win x64. I'm certain there are other big ones, but those are two big and obvious ones to me.

Microsoft has routinely left in holes in their OS that can't be easily fixed because a major software developer can't be bothered to fix their software.

I'd love to hear some examples of this.

So give credit to Microsoft for maintaining backwards compatibility, but you are just thanking them for providing a buggy OS that allows viruses to run rampant.

I didn't realize PowerPCs were a huge security hole. Or that every single API Microsoft still supports is riddled with huge security holes. Yes, it's definitely bad to leave in buggy APIs and inherently having much more API code greatly increases the chance of some of it being buggy*. But, that doesn't inherently justify creating multiple APIs to cover the same functions over 10 years or deprecating and then dropping the oldest--that alone is just API churn. Microsoft tends to be guilty of a lot more of the former than the latter and Apple seems guilty of both.

*Considering that *nixes tend to includes multiple overlapping APIs for which most users probably have part of a few installed at once, one can draw a similar concern for them as well.

Re:#ifdef APPLE_HARDWARE

[Anonymous Coward]

I'd love to hear some examples of this.

IE, specifically IE 6 and the debacle that is ActiveX.

Re:#ifdef APPLE_HARDWARE

[Anonymous Coward]

JWZ complains that Apple made a bad API.
Syousef counters by mentioning that Apple has every right to do such errors.

I'm going to follow the example by yelling that Syousef is indeed allowed to make non-sequiturs and if anyone is frustrated by it they can go read some other website.

Re:#ifdef APPLE_HARDWARE

[M. Baranczak]

The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device

You're free to release an application that doesn't run?

it's not that far off from most any commercial library/OS

Absolute nonsense. This sort of thing is common on game consoles, but on every other type of OS it's unheard of. Mac OS, Windows, Linux, Palm, Android - none of those platforms require you to get permission from the company before you publish an application.

Re:#ifdef APPLE_HARDWARE

[ClosedSource]

"Microsoft maintains strict backwards compatibility at all risks.And this is the big difference between Microsoft and Apple. Microsoft cares more for their developers and the companies that make money off of them than they do their users. Apple cares more about the users than they do about the developers."

Sure, the last thing users want is to have their old applications run on the new OS when they could just wait for vendors to upgrade and then buy the new version.

Re:#ifdef APPLE_HARDWARE

[10101001 10101001]

The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device

You're free to release an application that doesn't run?

Thanks for butchering what I said. Note what you chopped off "(either by buying the app through an app store or paying a set fee to the company)". The point being is, if you compile an app to run on Windows and don't have Windows, you have to (or someone else has to) pay Microsoft to run that app*.

it's not that far off from most any commercial library/OS

Absolute nonsense. This sort of thing is common on game consoles, but on every other type of OS it's unheard of. Mac OS, Windows, Linux, Palm, Android - none of those platforms require you to get permission from the company before you publish an application.

Okay, "not that far off" may be too close of a wording. But, as far as I can see, there's nothing to stop someone from releasing their pre-signed iPhone applications to other users and those users enrolling in the iPhone Developer Program to sign and run those applications on their own iPhones. To that end, the $99/year iPhone Developer Program fee translates into little more than a sort of software rental fee. Yes, I don't believe that's what Apple intended, and I'm not sure if they'd allow that sort of thing to continue to happen. If that's the case, then I agree my statement was absolute nonsense.

*Yes, there's Wine, but Wine isn't perfect. And presumably if one made an iPhone OS clone, one could run apps and bypass any seeming control that Apple has. As it stands, though, to run an app for a commercial platform tends to entail paying a fee to the platform's owner, be it once or repeatedly.

Re:#ifdef APPLE_HARDWARE

[jedidiah]

> To some extent, it's not that far off from most any commercial library/OS

This is total "swimming in the cool-aid" nonsense. NO ONE ELSE restricts you to the same level that Apple does.

They've even managed to find a way to be more restrictive than the game consoles.

They by no stretch of the imagination anywhere near comparable to "most any commercial library or OS".

You've got to be a totally mindless cult follower to manage a claim like that.

I'm not sure the Catholic Church has lay apologists that blindered.

Re:#ifdef APPLE_HARDWARE

[Anonymous Coward]

They used to. Recently they changed their mind and quit doing this. Joel on Software has an interesting article on exactly this: http://www.joelonsoftware.com/articles/APIWar.html

Re:#ifdef APPLE_HARDWARE

[syousef]

Um, not quite. The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device (either by buying the app through an app store or paying a set fee to the company). This isn't too far off from the XBox 360, either. To some extent, it's not that far off from most any commercial library/OS (the main difference is whether you effectively pay the fee upfront or whether they try to nickel and dime you later).

What are you talking about? Your first point is pedantry at it's worst. I can't run the software without Apple's consent, so who cares if I can physically install the file?

Your second point is just FUD. I've released minor pieces of freeware for Windows on the PC and no one came back and told me what I could or could not run on the machine or prevented me from running a thing. There are multiple completely free development environments available that leave me with free to distribute executables that will run on any machine without consent from the hardware or OS manufacturer.

Re:#ifdef APPLE_HARDWARE

[syousef]

That said, I don't really care for Apple's walled garden approach to the iPhone and for those of us nerds, it is a major problem (I've had to jailbreak just for simple things like Googlevoice front ends...or tethering)...for the average user? not a problem. The point is, Apple cares far more for the user than the developer. Microsoft doesn't give a fuck about the user so long as the developers are happy.

Leaving users out in the cold for common features is not caring for the user. Apple cares for Apple. Microsoft cares for Microsoft. No one gives a shit about the user, they just have different approaches to generating sales. Thinking otherwise is naive.

Re:#ifdef APPLE_HARDWARE

[savuporo]

Its 2010, who the hell still uses #ifdefs ? a code fork right in the middle of your core codebase ? Because thats what every #ifdef is, a branch. Unless is tightly contained in some portability wrapper class somewhere, and very well unittested at the interface layer. Even then, your portability layer should take care most of that for you. Otherwise, every #ifdef in the code will create two mutations of your code which make it harder to test, and two #ifdefs on different not mutually exclusive variables will result in four. Lets not go further .. Still need a branch ? Well, use hg or bzr or git as the good lord intended.

Re:#ifdef APPLE_HARDWARE

[exomondo]

DOS games on WinNT. Win16 on Win x64. I'm certain there are other big ones, but those are two big and obvious ones to me.

Those aren't API changes - which is the context of this discussion - those are major architectural changes. You can't expect compatibility that transcends architectures and operating systems.

Re:#ifdef APPLE_HARDWARE

[Anonymous Coward]

"Leaving users out in the cold for common features is not caring for the user. Apple cares for Apple."

Never said they didn't. Their approach is to care for themselves by making certain the users are protected...at the cost of developers.

Everyone cares for themselves first, and the bases their actions on how they treat others accordingly. It is human nature. Businesses are run by humans.

I will point out for clarification, the reason I was able to get out of programming and go back to school for medicine was entirely based around a round of funding where both Microsoft and Apple invested heavily. (for the record, there are a number of companies out there that are co-owned by the two if one looks close enough at the investments...I don't know if either are involved with the company at this point...neither were at the time I left). I have friends at both companies. And I can safely say, as a developer, I like dealing with Microsoft platforms...there are dozens of ways to get code into their machines. As a user, it is the opposite.

But back to the point, you are wrong. Just because someone has themselves in the primacy, does not mean that a close secondary could not be the user (or the developer). All actions are based on self-preservation if you look at the right level (even suicide is self preservation in some ways...of the species or even just preservation of the ego to ensure that it remains intact). Anything else is secondary. Get that past your head and you might not see things in such black and white.

Re:#ifdef APPLE_HARDWARE

[10101001 10101001]

DOS games on WinNT. Win16 on Win x64. I'm certain there are other big ones, but those are two big and obvious ones to me.

Those aren't API changes - which is the context of this discussion - those are major architectural changes.

You're mostly right. Never the less, DOS and Win16 APIs were dropped in Win x64 unnecessarily. AFAIK, even though Long mode doesn't support VM86, all non-x86 WinNT lines already had an emulator in NTVDM, so it would have been quite possible to continue support of DOS and Win16 APIs in some capacity if desired. Put in perspective, Microsoft effectively upgraded the Win16 API to the Win32 API and deprecated the usage of the Win16 API. The architectural change meant having an excuse to finally cut having to support the Win16 API. As well, it seems, Win32 for 64-bit Windows also drops some deprecated Win32 API calls (although Wikipedia doesn't mention which ones).

You can't expect compatibility that transcends architectures and operating systems.

While I can't expect such compatibility reasonably, Microsoft, Intel, AMD, and BIOS makers have all seemed to have made it their mission to continue support of programs written in 1981 for a 256KB, 16-bit processor without any modification. Ie, it's quite possible to boot some version of DOS (or Windows 9x, barring some memory issues) and run some program in 1981 on the highest end Intel system available. Microsoft and others have tried to push an unreasonably expectation of compatibility as the norm; they've fallen short at times. Hence, I applaud their efforts, but I can still point at their failings.

Re:#ifdef APPLE_HARDWARE

[syousef]

Like Apple, you forget what the computer revolution is all about and why people buy these gadgets. They buy them for the things that these gadgets allow people to do. As you restrict that in a misguided attempt to protect them, you make the device less useful. As you lock out developers you reduce those capabilities. Apple has it more wrong than most.

Re:#ifdef APPLE_HARDWARE

[exomondo]

You're mostly right. Never the less, DOS and Win16 APIs were dropped in Win x64 unnecessarily. AFAIK, even though Long mode doesn't support VM86, all non-x86 WinNT lines already had an emulator in NTVDM, so it would have been quite possible to continue support of DOS and Win16 APIs in some capacity if desired.

They are supported to a degree, through the use of XP Mode in windows 7 even the latest 64bit OS is able to run old 16bit applications, I shouldn't think there is much need to expend effort supporting Win16 beyond that.

I'd say the incredibly vast majority of developers are quite happy for Win16 to no longer be supported in the latest development tools. You can run your old programs in the latest OS, you can develop them with the older development tools, really what more do you need?

Re:#ifdef APPLE_HARDWARE

[10101001 10101001]

They are supported to a degree, through the use of XP Mode in windows 7 even the latest 64bit OS is able to run old 16bit applications, I shouldn't think there is much need to expend effort supporting Win16 beyond that.

My understanding of XP Mode is that it's even more in-a-bottle than WoW was. Beyond that, XP Mode really doesn't do anything about DOS games. And it does make me worry that Microsoft might pull an Apple (ie, dropping XP Mode in the future like Apple dropped Classic Environment) given the demands of having to effectively keep up to date two OSs.

I'd say the incredibly vast majority of developers are quite happy for Win16 to no longer be supported in the latest development tools. You can run your old programs in the latest OS, you can develop them with the older development tools, really what more do you need?

I agree that you're right. Most developers probably like the idea of removing older, obsolete API with a virtual machine for those who want to run older programs. Perhaps I'd be less cranky if they included a (good) DOS mode? :)

Re:#ifdef APPLE_HARDWARE

[exomondo]

My understanding of XP Mode is that it's even more in-a-bottle than WoW was. Beyond that, XP Mode really doesn't do anything about DOS games.

Yes, that's true but i don't really see a way around that. Unless you want to constantly update your deprecated APIs to work with the new underlying operating system you are going to have to sandbox it somehow.

It would be nice if they had the resources to keep all those old APIs compatible with all the new features but it's just not worth it.

And it does make me worry that Microsoft might pull an Apple (ie, dropping XP Mode in the future like Apple dropped Classic Environment) given the demands of having to effectively keep up to date two OSs.

The difference being that - as you said - you can run even those old unsupported OSes on even the most modern hardware, or alternatively a virtualized mode or even a full virtualized environment. With Apple you can't run their OSes in a virtualized system and the older apple OSes won't run natively on the current intel hardware.

Never underestimate...

[Anonymous Coward]

...the power of JEWS.

Re:Never underestimate...

[Anonymous Coward]

Do you mean JAWS? Because that would make sense.

Re:Never underestimate...

[Hal_Porter]

No, Java Enterprise Web System I believe. I see a lot of self parodic posts blaming that API for all manner of implausible ills.

Re:Never underestimate...

[Anonymous Coward]

Just like with the Jews.

Re:Never underestimate...

[x2A]

Blame and credit alike... it does claim that if you read C code into memory, that it can then parse the read C, but I don't think it could parse the read C, which is why the java is being used for things it really doesn't want to be used for in Egypt to this day.

Something tells me he orders BigMac at Burger King

[jo_ham]

the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right?

And at the core, they are - they share a large amount of code, with iPhone OS running a slightly modified version of the Darwin kernel. Where they diverge though, might have something to do with the whole UI being completely different. I assume he just didn't realise that the UI was different, since that seems to be the level of discourse available. So an app written for OS X, using a window manager with a point and click mouse and variable screen res, just dropped right onto a fixed resolution, touchscreen device.... Right. No need to change any code! (or rather, it'll be a simple case of "if iphone then do x..").

I'm all for criticising the iPhone's genuine faults, but this sounds like a kid who threw his toys out of the pram and is whining to get them back, only to want to throw them out again.

Let's look at what JWZ said...

[el_flynn]

In TFA, JWZ said "It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right?"

FLAMESUIT ON
At the risk of being shot down by every MacOS/iPhone hacker here... There are two main points that JWZ makes which are quite interesting:

1) I refused to fork the MacOS X code base
2) the desktop and the phone are both supposedly within spitting distance of being the same operating system

So the beef he has, while totally valid is because of:

a) refusal to fork the codebase
b) assumed that both iPhone OS == MacOS X

Hmm. I understand the refusal to fork the codebase, but if that's what's _required_ then that's what needs to be done to have the app on the iPhone. And what's the other bit about "assume" making an ass out of you and me? Ditto for the OpenGL/OpenGLES rant...
FLAMESUIT OFF

Re:Let's look at what JWZ said...

[SharpFang]

IF the code requires forking, THEN it should have no pretenses about being cross-platform compatible.

Which was the original point.

It's not a complaint that iPhone is devilishly difficult to program. It is not. The complaint is that it's devilishly difficult to write an iPhone/desktop cross-platform compatible app, which should have been easy if the device actually was cross-platform compatible.

Re:Let's look at what JWZ said...

[mwvdlee]

I don't really care about developing for any Apply product myself, so I haven't looked into it in-depth, but does Apple actually claim OS-X and iPhone development is cross-platform compatible?

Re:Let's look at what JWZ said...

[Shadowmist]

So after the decades of the Slashdotters complaining about MacOS being MacOS, thier complaint about the iPhone OS is that it's NOT MacOS? What IS the OP smoking? Where where all of you when it was made abundantly clear that the iPhone and especially the iPad were not to be treated as shrunken down Macs? And throw away any of that objection about the iPhone not being "open" that argument leaves the building when you decide to develop for the device.

Re:Let's look at what JWZ said...

[Bungie]

I don't get it though...why would you want to write a cross platform app between a desktop OS and a smart phone with the same UI? That what made Windows Mobile a disaster, having to navigate apps designed for a desktop UI on a small screen with a stylus.

Re:Let's look at what JWZ said...

[drinkypoo]

So after the decades of the Slashdotters complaining about MacOS being MacOS, thier complaint about the iPhone OS is that it's NOT MacOS?

Reading comprehension fail. The complaint about the iPhone OS is that it IS MacOS, but that it's castrated in completely inexplicable ways, and the changes smack of incompetence.

Re:Let's look at what JWZ said...

[TheKidWho]

Incompetence, yes that's what you call selling 85 million+ devices running the OS.

Re:Let's look at what JWZ said...

[Savage-Rabbit]

It's not a complaint that iPhone is devilishly difficult to program. It is not. The complaint is that it's devilishly difficult to write an iPhone/desktop cross-platform compatible app, which should have been easy if the device actually was cross-platform compatible.

Anybody expecting it to be easy to take an app which was written for a desktop system and porting it to a mobile system is going to unpleasantly surprised. Porting is always a bitch and if the platform you want to port to is less capable than the one you originally wrote the app for you'll have allot of work ahead of you. Even in CP languages like Java you'll have problems since the Java implementations for mobile platforms aren't as capable as their desktop counterpart and there are always issues with implementations for different mobile platforms. Mobile development is also subject to totally different laws than desktop GUI app development often is. There are limited resources which leads to more limited APIs which means either using the least common denominator or getting ready for an awful lot of #ifdeffy. If you really want to write an app for both desktop and mobile systems you have to write it with that in mind from the very beginning. This means manual memory management, using only the lowest common denominator in terms of APIs, programming languages, etc... and you better get your MVC separation straight from the very beginning as well since you are going to have to write separate UI's for each platform. Mobile UIs tend to be fundamentally different in concept from desktop UIs. You'll also want to write as much of your app as possible in platform independent modules that can be 'plugged into' your apps as required.

Re:Let's look at what JWZ said...

[drinkypoo]

Incompetence, yes that's what you call selling 85 million+ devices running the OS.

By the logical extrapolation of your argument, Windows NT is the finest operating system on the planet.

Re:Let's look at what JWZ said...

[ColdWetDog]

By the logical extrapolation of your argument, Windows NT is the finest operating system on the planet.

No, that would be EMACS.

Re:Let's look at what JWZ said...

[DarkOx]

Exactly the issue is not that tools are not cross platform or that the iphone is not compatibile with the Mac; that is not really surprising. The problem is Apple marketing said they were, when they are not. Its like Microsofts claim .Net is cross platform; sounds nice but lets be honest. .Net runs on what Windows or Windows x64. A small subset of what is considered "platform" on Windows is there for use on Windows Mobile; such that unless your app is trivial you are probably looking at a serious porting effort; and we all know you are not going run your .Net application at all on Big non x86 UNIX, Mainframes of any kind or embeded devices not running Windows Mobile. These are all places Java(much as I am not a fan) can go with very little porting effort which makes the claim .Net is cross platform appear pretty crazy.

Re:Let's look at what JWZ said...

[LingNoi]

The GP said "incompetence" because of the API changes. It has nothing to do with units sold.

If you can't read comments please don't make your own.

Re:Let's look at what JWZ said...

[nacturation]

Incompetence, yes that's what you call selling 85 million+ devices running the OS.

Right... because popularity always equals competence. You must be a Britney Spears fan.

Re:Let's look at what JWZ said...

[Anonymous Coward]

... which should have been easy if the device actually was cross-platform compatible.

Can you site one instance of where anyone at Apple ever said that the iPhone and OS X APIs were to be identical, or even very close?

Initially, they did say that iPhone inherited all of OS X's fancy graphics and stuff...but that was a user-interface statement; back then they were saying they wouldn't open it to outside development at all

Re:Let's look at what JWZ said...

[beelsebob]

The complaint is that it's devilishly difficult to write an iPhone/desktop cross-platform compatible app, which should have been easy if the device actually was cross-platform compatible.

Which, at a guess, was apple's intentions in making a completely new UI framework for the iPhone. What they absolutely did not want under any circumstances was a bunch of poorly ported desktop apps, with the exact same user interface, in such a way that nothing worked right.

Re:Let's look at what JWZ said...

[TheKidWho]

Windows NT is a damned good OS for the time it was made.

I don't think the changes were out of incompetence either, the bunch at Apple seem to be fairly competent in what they are doing. To me it seems like something that was necessary to go from a Mouse/Keyboard based UI to a multitouch one.

Having used both the old and new Palm dev tools and the Windows Mobile dev tools back when it was pocket pc, developing on the iPhone is much less painful.

Re:Let's look at what JWZ said...

[SharpFang]

Porting J2ME phone midlet to J2SE runtime is not hard at all.

Sure you must take device limitations into account. But that's not the case here!
First, the app was not really being "ported for", but rewritten for both simultaneously. Then, they were supposedly the same OS. And last but not least, the app in question was dead simple: display a monochrome bitmap on screen, animate it.

The problem was that Apple developers went to some lengths to make the two deeply incompatible - in parts that could be easily compatible because they do the same thing, they take (functionally) the same parameters, and produce the same results... except they are named differently, they use different types of arguments (with the same meaning) and so on.

Re:Let's look at what JWZ said...

[SharpFang]

Okay, but what's so bad to have a good phone app ported to desktop, say, as a desktop widget, with support added for full keyboard and using the extra CPU power? A weather gadget, a RSS ticker, a clock, a post-it notes app, this kind of thing. It should be trivial, shouldn't it?

Re:Let's look at what JWZ said...

[MisterZimbu]

That doesn't mean the developer or the framework was competent. Just that marketing was.

Re:Let's look at what JWZ said...

[drinkypoo]

Windows NT is a damned good OS for the time it was made.

Sorry, but I remember the early versions of NT, and I've used the recent versions, and I'm not clear on what era it could be considered to be a "damned good OS" in. Its functionality and stability was pathetic compared to any commercial Unix when it was introduced, and it's a security fuckfest today. If you were comparing it to Windows 3.1 and DOS, then you might think it was a real operating system, and not a rube goldberg nightmare of tinkertoys.

I don't think the changes were out of incompetence either, the bunch at Apple seem to be fairly competent in what they are doing. To me it seems like something that was necessary to go from a Mouse/Keyboard based UI to a multitouch one.

This is utterly, totally false. In fact, OSX can do Multitouch with little modification.

Having used both the old and new Palm dev tools and the Windows Mobile dev tools back when it was pocket pc, developing on the iPhone is much less painful.

I understand not wanting to have ports of desktop apps clogging the app store, but what Apple has actually accomplished is not to prevent those ports, but to make porting those applications more difficult, which means that developers creating these ports will make more mistakes. Thus Apple has only succeeded in reducing the quality of ports by making porting more difficult. Since so much of what Apple did was just renaming existing methods, it's hard to defend their actions from a performance standpoint. The relative difficulty of developing for Palm operating systems is a Red Herring; it has no bearing whatsoever on Apple's development system, or the development experience of the iPhone as it compares to OSX, which is what we're actually talking about today. Stay on topic.

Re:Let's look at what JWZ said...

[Anonymous Coward]

Why not? My Droid all but eliminated my need for my laptop and completely cancelled my interest in getting a netbook. What I would normally use both for, I've switched to using my Droid for. Basic document/image viewing/manipulation, basic web browsing, basic communication, and even telnet. But - there are times where I want to start a document on my phone, pass it to my computer for further editing, and allowing said document to be easily transferred with very little fuss and very little changes in the UI out of the "norm." The integration should be seamless. //Begin Flamebait
Microsoft's new cross-platform game thing, where you can start a game on the 360, continue it on the PC, then further continue it on a Windows Phone 7 device is exactly what I had in mind for the iPhone when I had my 2g, but it was never achieved. Now that I have my Droid, it's a bit closer, but still not "there" yet. For once, Microsoft is on the right track. My question is, if a company that traditionally botches things is getting somewhere and actually innovating the cross-platform capability, why can't Mac do the same with theirs, aside from what appears to be laziness and/or unwillingness to do so on the part of Apple? //End Flamebait

Re:Let's look at what JWZ said...

[dzfoo]

You know, I've never seen this claim from Apple. Their tutorials and documentation does mention that it is fairly straight forward to translate your skill set from one to the other, but I've never seen it even suggested that cross-compilation between OS X and iPhone OS was possible.

          -dZ.

Re:Let's look at what JWZ said...

[dzfoo]

Can you please offer an example of such Apple marketing? I will not outright deny it exists, but I have never seen it mentioned that both platforms are even close to compatible for development purposes.

        -dZ.

Re:Let's look at what JWZ said...

[jo_ham]

So, in your world, the API for a variable resolution, mouse+keyboard driven GUI should be the same API as a fixed resolution touchscreen? And you think it's "incompetence" that the APIs are different for two interfaces that are different in size, input device and resolution, one of which can be rotated on the fly into different orientations?

You are surprised that an app that has existed for nearly 20 years on multiple platforms wasn't trivially easy to port to the iPhone because the developer was just too stubborn to understand that perhaps the API is a little different on the iPhone than on OS X despite them being "within spitting distance of each other" (which they are, below the GUI)?

Sure, there are a couple of inconsistencies that could have been in core frameworks shared by both platforms, but they are hardly game changing or enough to whine on the internet about.

Next you'll be telling me it should be super easy to make a KDE app look *identical* when running on a Gnome desktop with no inconsistencies or graphical issues at all. I'll bet that was super easy to get all the bugs ironed out of that. I'll bet it took less than an afternoon to fix it.

Re:Let's look at what JWZ said...

[jo_ham]

Windows NT was awesome, actually.

Had a lot of good memories with that thing.

Re:Let's look at what JWZ said...

[larry bagina]

just think of how many more iphones they would have sold if it had a scroll ball/mouse instead of this touch shit. Users don't want to run a single application, they want to move windows around and navigate menus and right click on shit. lame.

Re:Let's look at what JWZ said...

[ClosedSource]

Cute, but the criteria included selling.

Re:Let's look at what JWZ said...

[Anonymous Coward]

well, Jamie is getting old. All I heard when reading his rant summary was "HEY! You kids get off my lawn!"
who cares about daliclock anyway? its a really lame app from 1995 --- remember all the root exploits and
buffer overflow errors in xscreensaver??

please JWZ -- just shhh...

Re:Let's look at what JWZ said...

[ClosedSource]

I developed for NT for a number of years and I didn't see a problem with stability. The only thing I noticed was that Lotus CCmail would crash all the Windows 9x machines and we NT users would just carry on as if nothing happened.

Re:Let's look at what JWZ said...

[ClosedSource]

If they said they both the Mac and the iPhone used the Mac OS X and didn't qualify that statement, then it's reasonable to assume the APIs are the same.

The problem is that everybody seems to be defining an OS as a brand rather than a specific functional set. How much can you remove or change in an OS and still legitimately give it the same name?

Re:Let's look at what JWZ said...

[Anonymous Coward]

Given that Apple have been quite clear up front that the UI libraries for the iPhone are based around a new API called "Cocoa Touch" that operates quite differently from the Mac OS X "Cocoa", I would like to know how application UIs could ever have been straight up compatible, even when simple like this case.

An application's data model and non-UI could be mostly compatible however, because the systems use the same programming language and frameworks. You'll just need a new view that is targetted for the device.

In this case, a simple clock application doesn't have much in the way of a data model or controller, so you end up having to pretty much rewrite the entire application.

Re:Let's look at what JWZ said...

[Anonymous Coward]

it should have no pretenses about being cross-platform compatible.

The notion that it should have been an effortless one-click recompile was Jamie's assumption, and it's unsupported by anything Apple has actually said or claimed. Apple states that porting is easy because of the similarity between Cocoa's AppKit and the iPhone's UIKit. And they're right - it's *far* easier to port a Cocoa app than (for example) a Java, .NET, or Qt app.

IMHO, a better title for this story would have been "JWZ whines in blog when reality fails to adapt to assumptions."

Re:Let's look at what JWZ said...

[3dr]

JWZ's rants hinges on two points, based on assumptions that are false.

The first being, that iphone OS is (or should be) identical to OS X desktop/cocoa. I've been developing on OS X desktop for about three years, and iphone about a year. Never have I heard the claim (by Apple or anyone else) that the code is portable. It simply is not. In fact, Apple's iphone introductory videos explicitly mention that developers must think differently about a portable device in terms of what kinds of apps are good for portable devices, how the user interacts with it, etc. I do agree with him, that if the libraries are named the same and represent the same technology, they should work identically.

Other people are picking up this idea of source compatibility and running with it, but it's a straw man because Apple never claimed 100% source compatibility.

And second, he assumes OpenGL ES is identical to OpenGL. I think that a reasonable person, when hearing the release of an API specifically for embedded systems, would think there may be some limitations or differences in the new implementation since by definition, embedded systems have limitations and features different from the desktop environment. So he learned that there are API differences. Some people would just move on with this newly found knowledge, while others blog a rant about it.

Much ado about nothing.

Re:Let's look at what JWZ said...

[Shadowmist]

the Iphone OS is not and has never been stated to be MacOS. It has some relationship to MacOS but that is in the underlayers not the overall GUI. The OP is simply a lazy coder who is trying to shoehorn one paradigm into another, who apparantly refuses to consider that a UI designed for a Hi resoution monitor and pointing device can not be the same kind of UI set up for a small screen and fingertip control. So...yes Fork or be dammed.

Re:Let's look at what JWZ said...

[Blakey Rat]

Their noisy fanbois certainly do. I don't know how many thousands of times I've read, "but the iPhone runs OS X, same as your laptop!" on Slashdot.

But yah, I'm not sure I've ever seen that claim from Apple themselves.

Re:Let's look at what JWZ said...

[supssa]

The iPhone certainly does run OS X under the hood, but Cocoa and Cocoa Touch are certainly different. It's the QT vs GTK comparison that has been made REPEATEDLY in this article's comment mess.

Re:Let's look at what JWZ said...

[fuzzywig]

I terms of the basics, such as 'I'd like this colour displayed here please', then yes, it should be the same between OSX and the iPhone. Obviously there will be some differences, but isn't it more logical and better for everyone, to take the OSX version and just change the things that have to be different between the two, leaving as much as possible the same is better for the people programming the API (less work), and the programmers using the API (less new stuff to learn, or change). Gnome and KDE are different window managers from different teams, they make no claims to be the same, where as Apple has specifically tried to make developing for OSX and iPhone as similar as possible, basically, that was a crap example.

Re:Let's look at what JWZ said...

[jo_ham]

A crap example? Two different window managers are "more similar" than a *mobile phone* and a desktop computer, even if they are made by different teams.

The iPhone and OS X devs are different teams too, just like the KDE and Gnome teams, except within the same company, and Apple make no assertions that it is trivially easy to port a desktop app without rewriting some parts of it. The KDE and Gnome teams also produce window managers that run on top of the same base system. The iPhone and OS X teams target totally different hardware platforms.

The example seems perfectly valid to me - the differences between porting apps between iPhone OS and OS X are even more pronounced than between KDE and Gnome, and it's not trivial for either setup, despite lots of common links between them (KDE, Gnome > on top of Linux versus iPhone, OS X > based on common software).

Re:Let's look at what JWZ said...

[maxume]

I read his ranting as a complaint that the changes seem arbitrary and unnecessary, not that they happened.

If the changes made sense to him, he would be less bothered by them.

Apple is like...

[Anonymous Coward]

Imagine being able to buy a Dodge Viper for $20,000. A good deal right? Now what if part of the deal, you could not drive the car out of the state, and you cannot go more than 50mph in it, and if you break any of the agreements, you must actually pay the full $80,000.

Anyone want to take the deal?

My point is, if you buy something, you should be able to do WHATEVER THE HELL YOU WANT WITH IT.

- From a PC.

Re:Apple is like...

[Kooty-Sentinel]

No.

More like Audi/BMW putting a 250 km/h speed limiter on the car you just bought. Sure, you can go ahead and remove the limiter yourself, and why the hell not change the fuel mappings on the ECU while your at it? Audi/BMW will not support the modifications nor honor the warranty on your car, but there's nothing 'physically' stopping you from making the modifications. They are by no means obligated nor legally required to tell you how to circumvent their limitations and reverse engineer their software.

When an engine suddenly catches on fire doing 270 km/h+, or you suddenly loose control on the car, the last thing they want is for you to point the finger at them and say: "Well you technically allowed us to do this". They are just doing everything possible to cover their asses.

Look at Windows Mobile for a minute. Stock installs are actually quite decent. But when Joe Sixpack starts installing "Bubble Popper 2.0", and "FREE XXX PIX" on his phone, and the phone shits a brick, guess who takes the blame? Yeah, Microsoft and their "damn unreliable OS".

Re:Apple is like...

[Anonymous Coward]

Look at Windows Mobile for a minute. Stock installs are actually quite decent. But when Joe Sixpack starts installing "Bubble Popper 2.0", and "FREE XXX PIX" on his phone, and the phone shits a brick, guess who takes the blame? Yeah, Microsoft and their "damn unreliable OS".

This is true of Windows desktop as well.

Re:Apple is like...

[Anonymous Coward]

Your analogy only holds up if you assume that there are no public roads, and that Audi/BMW has a contract with the owners of the roads which prohibits you from using the car on the roads if you've made any un-approved aftermarket changes.

Re:Apple is like...

[Anonymous Coward]

or you suddenly loose control on the car

Most cars exist for the very purpose of the driver loosing his control upon the vehicle.

Re:Apple is like...

[julesh]

Audi/BMW will not support the modifications nor honor the warranty on your car

Actually, at least here in the UK, they are legally obliged to honour the warranty, unless they can provide reasonable evidence that your modifications caused the fault you want them to fix. My suspicion is that the situation is similar elsewhere.

Re:Apple is like...

[Anonymous Coward]

BMW allows you to buy aftermarket parts which don't void the warranty a la DINAN, HARTKE, etc. Most high performance vehicles have a way that you can modify them to exceed normal operating limits without voiding the warranty.

Re:Apple is like...

[Kooty-Sentinel]

Audi/BMW do not prohibit you from using the car on roads though. Apple does not prohibit you from using jailbroken phones on the iTMS.

Sony does that with PSPs and Microsoft does that with XBoxes - but mostly for anti-cheat reasons. To put it in a car analogy, DOT prohibits illegal modifications from driving on public roads since they would hinder the safety of other drivers.

Re:Apple is like...

[supssa]

Audi puts that limiter on because their shitty front wheel / half-assed transverse 4wd cars (TT, A3) would be unhand-able.

Re:Apple is like...

[exomondo]

Same here in Australia.

Re:Apple is like...

[Anonymous Coward]

Look at Windows Mobile for a minute. Stock installs are actually quite decent. But when Joe Sixpack starts installing "Bubble Popper 2.0", and "FREE XXX PIX" on his phone, and the phone shits a brick, guess who takes the blame? Yeah, Microsoft and their "damn unreliable OS".

Citation, please. Pulling bullshit imaginary scenarios out of your anus isn't evidence.

jwz

[Anonymous Coward]

Who is JWZ?

John William Zoidberg?

Re:jwz

[Anonymous Coward]

jwz = Jamie W Zawinski (Yes, he has a single-letter middle name, because he's that awesome.)

A great hacker whose name you are not worthy to speak.

Re:jwz

[Anonymous Coward]

I don't know ... the name definitely has a douche-y quality to it.

Re:Something tells me he orders BigMac at Burger K

[SharpFang]

The problem is not that the UI is -completely- different.

It's an UI that is massively the same, just ran through a bulk rename, shuffle parameters order around in function calls and explode/implode some methods / typical sequences.

The UI -could- have been VERY similar, with only minimal differences easy to #ifdef through - the underlying philosophy is. Instead, there was some active effort put in making it totally incompatible, where making it compatible would be easier and more obvious.

A typical case of "an extra week of writing code can save you a hour you'd spend on reading documentation instead."

Stop making apps, start making web-apps

[StripedCow]

Can we all please stop making apps, and start making web-apps?

Then we can all benefit from your development effort, and we are not restricted to buying apple hardware. As an added bonus, you don't have to bend to the idiosyncrasies of the iphone api.

Yes, I know, apps allow us developers to use the convenient micro-payment system which exists in the form of the app-store, but come on, there are plenty of other ways to get paid for your work.

In the meantime, it *would* be nice if some other big company (google?) would invent a micro-payment system similar to the app-store, but (of course) for web applications instead of for a proprietary platform.

Re:Stop making apps, start making web-apps

[Anonymous Coward]

Yes, I know, apps allow us developers to use the convenient micro-payment system which exists in the form of the app-store, but come on, there are plenty of other ways to get paid for your work.

In the meantime, it *would* be nice if some other big company (google?) would invent a micro-payment system similar to the app-store, but (of course) for web applications instead of for a proprietary platform.

Why should google do that when there are plenty of other ways to get paid for your work?

Re:Stop making apps, start making web-apps

[vadim_t]

No thanks.

Personally, I hate web apps. They're still vastly inferior to desktop applications. They need a constant connection, are less responsive than a desktop app, are limited in the GUI they can have, work or not depending on the browser, and are in many cases outside of my control, which is excellent for lock-in.

There still are many places where I have no internet connection. It happens when travelling in the underground. It's frequent above the ground in a train in some areas. It's unaffordable when roaming. It doesn't work in the middle of nowhere. I find it unacceptable to lose access to my stuff just because I happen to be somewhere without a cell tower.

What we need is more open architectures, where anybody can make anything they want without interference.

Re:Stop making apps, start making web-apps

[timmarhy]

this post wins fail of the day.

web apps are slow, lack features easily implemented in an exe and worst of all leave you even more at the mercy of some other asshole who could pull the plug on your app at anytime.

web apps have their place, but they aren't a solution to the apple syndrome.

Re:Stop making apps, start making web-apps

[betterunixthanunix]

"web applications instead of for a proprietary platform."

Almost all web apps, by their very nature, are proprietary. How many websites make their source code available? How many websites can you set up on your own web server? How many websites allow you to opt out of software updates (i.e. updates to the website itself)? Such examples certainly exist, but they are few and far between.

Re:Stop making apps, start making web-apps

[StripedCow]

Why should google do that when there are plenty of other ways to get paid for your work?

To make it a little easier.

They will benefit from an increased focus from developers on the web (their core business) instead of on apple products (on which they have no grasp).

Re:Stop making apps, start making web-apps

[arth1]

Personally, I hate web apps. They're still vastly inferior to desktop applications. They need a constant connection, are less responsive than a desktop app, are limited in the GUI they can have, work or not depending on the browser, and are in many cases outside of my control, which is excellent for lock-in.

Hear, hear!

In addition to not being future-proof. I predict that any data will be inaccessible in a mere decade or two, and you can't just boot up a 15 year old and compatible version of your web app, even if the company should exist down the road.
Which, incidentally, is a big problem. As an example, much of JWZ' source code is 20+ years old.
I for one, is happy that he didn't store it with a properietary editor running under EMBED, stored in Netscape's old roaming storage. :-)

Speaking of... who sits on the old Netscape source now? Oracle?

Re:Stop making apps, start making web-apps

[Trepidity]

Not sure it answers all your concerns, but on the iPhone at least, you can package up a web-app so it installs locally. Then it's basically a local app that happens to be written in Javascript and render via the Webkit toolkit.

Re:Stop making apps, start making web-apps

[StripedCow]

this post wins fail of the day

But I still got modded +4 interesting at the moment, haha.
However, I do agree with you to some point.

web apps are slow, lack features easily implemented in an exe

True, however, with HTML5 things will improve. The current javascript engines are sufficiently fast to allow most complicated tasks. Further, there are technologies in beta which allow execution of machine code in the browser (in a sandboxed environment). See google code/labs (I forgot the name of that project). This may eliminate problems with performance of web apps altogether, in the (hopefully near) future.

and worst of all leave you even more at the mercy of some other asshole who could pull the plug on your app at anytime

Yes, I'd hate that too (even the thought of it). But web-apps can be programmed such that they function also off-line (although some better support in browsers would be nice).

Programming for the web is not perfect, but the web will evolve in an open way. If you are basing your code on the web, then at least apple can't pull the plug on the developer...

Re:Stop making apps, start making web-apps

[tepples]

on the iPhone at least, you can package up a web-app so it installs locally.

A web app developer still runs into problems with 1. device features that are available to Objective-C programs but not JavaScript programs running in WebKit, and 2. having to roll his own method of payment for the privilege of using the application.

Re:Stop making apps, start making web-apps

[tepples]

Why should google do that when there are plenty of other ways to get paid for your work?

To which "other ways to get paid for your work" do you refer? Selling support doesn't apply to all categories of application.

Re:Stop making apps, start making web-apps

[tepples]

with HTML5 things will improve.

Does HTML5 support two-way audio? Otherwise, it would be impossible to make, say, Skype into a web app. Does the 3D rendering context of the <canvas> element work? Otherwise, it would be impossible to make a lot of the games on the App Store.

Re:Stop making apps, start making web-apps

[Eskarel]

Web apps exist primarily to avoid all the pain of distribution and installation. If you code one properly, distributing the application to someone involves sending a link, and presuming they have an even moderately recent browser(ie released in the last 10 years) 99.999% of the time the application will "just work".

Now true, desktop apps have a lot going for them, and for people who know how to install, manage and maintain them, they're still vastly superior. Most people on the other hand don't know how to do those things, and pretty much every currently existing technology for reliably distributing them without having to send someone round to every PC involves having rather strict control over how the PCs are configured and what software is installed on them.

Re:Stop making apps, start making web-apps

[painandgreed]

Can we all please stop making apps, and start making web-apps?

Funny enough, that's what Jobs told everybody to do to begin with when the iPhone came out. Only after much bitching and gnashing of teeth did they get an SDK and the app store.

oh noes!

[hom3chuk]

First, if you can't modularize your code - it's not framework' fault.

Second, if a piece of code work like a clock (read: goodwritten), then you can port it to any modern platform with any modern language. That not includes special cases, e.g. porting from OGL ES 2 to OGL ES 1.

And third, don't fight against framework, use it perks instead. ifdefs is not a framework but compiler feature, it may not work fine with framework because framework was written for a particular device, not for a GCC.

Who is JWZ?

[AmonTheMetalhead]

And why should we care?

Re:Who is JWZ?

[Anonymous Coward]

I really don't think this is a troll. It's honestly a valid question, on both parts. If I had mod points, I'd fix this. If I had any clue who JWZ was, I'd answer.

Re:Who is JWZ?

[cg0190]

I have no idea either. It's like some geek in joke or something...

Re:Who is JWZ?

[Anonymous Coward]

Who is JWZ? An internet-famous geek celebrity. Hence the three-letter acronym. See also: RMS, ESR.

Why should we care? Because he insulted the iPhone, dude! That's like dressing up as Satan, going into the Vatican and pissing on the Pope. Except it isn't funny. Here is this big shot free-software-guy-turned-club-owner, Netscape and X11 apps behind him, who dares to suggest that his difficulties with iPhone development are somehow Apple's fault, rather than (as well all know) his own fault for being massively, massively retarded.

Re:Who is JWZ?

[chengkhoon]

http://en.wikipedia.org/wiki/Jamie_Zawinski

Re:Who is JWZ?

[fredrik70]

geek card, hand it over, now

Re:Who is JWZ?

[Anonymous Coward]

Congratulations to you and your parent poster for obviously being newfags. I guess IN GENERAL (note, it's OKAY to generalize, you will not burn in hell and it's not a sin against reason to make generalizations) you can judge a poster by his size of his ID.

Re:Who is JWZ?

[Anonymous Coward]

Who is JWZ? An internet-famous geek celebrity. Hence the three-letter acronym. See also: RMS, ESR.

Literate people call them initials , you dingleberry.

Re:Who is JWZ?

[will_die]

He owns & runs a bar/night club in california.

Re:Who is JWZ?

[Anonymous Coward]

I don't know him either.
Does he have a name, or is it just the initials?

Re:Who is JWZ?

[Anonymous Coward]

He runs a bar and used to write software 15 years ago.

I'm not sure either.

Re:Who is JWZ?

[AmonTheMetalhead]

It's funny how you demand my geek card whilst avoiding to demonstrate any knowledge on the subject at hand, you don't happen to work in the marketing department or on an executive level do you?

Re:Who is JWZ?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Jamie_Zawinski

According to the Wikipedia, he has a LiveJournal account. I can pretty much ignore what ever he has to say in light of that fact.

Re:Who is JWZ?

[Sir_Lewk]

Who is this Bill Gates? Why should we care what he says?"

Geek card, hand it over.

It's funny how you demand my geek card whilst avoiding to demonstrate any knowledge on the subject at hand

You realize how silly this sounds, right?

Anyways, the guy is a hacker and nightclub owner, well liked by many slashdotters for both making a gazillion shitton X screensavers, his awesome occasional rants, and proving he can have a successful life outside of the usual geekery. He also did some netscape/mozilla shit a while ago, but whatever.

Re:Who is JWZ?

[Anonymous Coward]

Also emacs hacker with issues with rms.

Re:Who is JWZ?

[elrous0]

Duh, he's the guy that created Babylon 5.

Re:Who is JWZ?

[AmonTheMetalhead]

Yea, found that out on the wiki link posted before, wasn't aware of him and TFS was sketchy with details to say the least.

Re:Who is JWZ?

[Anonymous Coward]

tsk tsk... you should have simply typed: about:jwz ( well if you were running Netscape Navigator anyway )

I don't blame you... he's not a genius, he was just a "first". He touched a few famous projects, and he got in early. BFD. He has made the mistake of a lot of oldbies ( including myself at times * ) of not staying on top and still having the attitude that he does.

His complaints about the iPhone SDK are true, but basically just make him look like a whiny kid. Mommy, the temperature of the pool isn't exactly what you said it would be, wha wha wha.

* I've been posting anonymously on Slashdot since 1998 and hadrly ever get my posts seen by anyone, yet I never register. Why? Oldbie who refuses to change,

Re:Who is JWZ?

[SuiteSisterMary]

IOW, he's an archetypical cyberpunk character. Former hacker and coder who now runs a bar/nightclub, who sometimes dispenses wisdom from on high, and whom newbs deride and experienced people listen to.

The only thing missing is moving stolen data or cyberware, and/or arranging squads of disparate professionals to perform quasi-legal or illegal actions against corporations, generally on the behalf of other corporations.

Re:Who is JWZ?

[Sir_Lewk]

Oh damn, I never even thought of it like that but you're incredibly right. Next we're going to find out he carries a katana and delivers pizza for the mob in his free-time... :O

Re:Who is JWZ?

[ClosedSource]

I think you're wrong. Just because a poster has a monster size ID doesn't mean his posts are more potent.

Re:Who is JWZ?

[ClosedSource]

"An internet-famous geek celebrity."

Old-timers would define the above as a n00b (if we adopted that newfangled leet language). Now get that Internet off my lawn!

Re:Who is JWZ?

[Anonymous Coward]

And why should we care?

because ad homenim is a logical fallacy.

Re:Who is JWZ?

[fredrik70]

known about him since his ranting about why he left netscape when they decided to chuck out the old code and start fresh.
Nope, not a manager nor exec, which is regrettable from a monetary point of view I suppose, otherwise quite happy
Doubt I'd make a good boss anyway.. far to grumpy...

So why is this guy and his Nerd Rage on /. ?

[Anonymous Coward]

See title

Want Real Cross-Platform? Try ZooLib!

[MichaelCrawford]

While the 68k Classic Mac binding hasn't been maintained for a while, it wouldn't be hard to get it working again. That would enable you to use the same client code all the way from the Mac Classic running System 7 to Mac OS X, Windows 7, Haiku, BeOS, Linux (mostly), BlackBerry and the iPhone.

All with one set of C++ client code, compiled to native executables for each platform.

If you want iPhone support, you'll need the Subversion source base; the code works, but we haven't rolled a release for a while.

• ZooLib C++ Cross-Platform Application Framework

Its Open Source under the MIT License, chosen specifically to be compatiable with both GNU GPL and proprietary development.

Web Apps Don't Work When You're Not Online

[MichaelCrawford]

What's worse, you're at the mercy of the web app vendor. If they take down their app or start charging more money for it, you're SOL.

Re:Web Apps Don't Work When You're Not Online

[Rocketship Underpant]

Web apps designed in HTML5 can indeed work when you're offline. However, you're definitely right about being at the mercy of the website.

Nobody Ever Claimed Cross-Platform

[SkydiverFL]

I suggest that you watch the very first dev video on beginning development for iPhone and Mac OS X and continue on from there. At no point does ANY of Apple's materials ever mention that you can write once and compile for both platforms. All they claim is that the tools and syntax and the same (XCode, Interface Builder, Objective-C, etc.). I've been programming for a few decades now and specialize in .NET. And, although I hated the experience of going from comfy C# to Objective-C, that's really the only pain. If you really look at how UIKit differs from AppKit, you may actually realize that it's the right tool for the job. Although Microsoft has paid the bills for quite some time now, I can honestly say that writing for Windows Mobile SUCKS... not because of syntax or compatibility issues, but because of the bloat and limitations of the mobile environment (Compact Framework on Windows Mobile). At least Apple got it right by accepting that the iPhone platform really IS a different animal, compared to a MacBook or Mac Pro, and built a more appropriate framework.

Properly cross-platform code cares not for the UI

[MichaelCrawford]

I haven't actually read TFA, but if he has a problem porting between Mac OS X and the iPhone, just wait until he tries to port his app to Windows CE, Android, BlackBerry and Symbian.

There are some important architectural points to keep in mind if you ever hope to take your application cross-platform. One is the separate the "engine" or core code cleanly from any kind of user interface. That way you can keep what is most fundamental about your application constant, then write a new UI to exercise it for each new platform.

Another consideration is to avoid using any platform specific APIs, formats or protocols for anything that extends outside of the application itself. I'm sure Apple's Core Data is the best thing since sliced bread - until you try to email a Core Data document to your buddy who's got an Android phone.

What is ironic is that the iPhone provides sqlite, which is a simple SQL database that keeps all its data in single files. sqlite is Open Source, and widely available, so you really could use an sqlite database as a user document, in just the same way that you couldn't do with a Core Data doc.

Re:Something tells me he orders BigMac at Burger K

[bar-agent]

The problem is not that the UI is -completely- different.

It's an UI that is massively the same, just ran through a bulk rename, shuffle parameters order around in function calls and explode/implode some methods / typical sequences.

The UI -could- have been VERY similar, with only minimal differences easy to #ifdef through - the underlying philosophy is.

No, the UI is completely different. Events are completely different, because of multi-touch-related stuff, and consequently, everything else needed to be rewritten as well. It shares naming conventions and some concepts with Mac OS X's AppKit, but that's all. Focus is different, windows are different, views are different, the first responder is mostly unused, etc.

Re:Want Real Cross-Platform? Try ZooLib!

[Anonymous Coward]

Their list of applications that use zoolib is suspiciously short - only three links, of which two are broken, and the third is a web app.

I'm thinking this is worse with Windows CE...

[cmowire]

As far as I can remember from when I did some Windows CE hacking, that's actually worse than the difference between Windows CE and standard Windows.

Wow.

Re:I'm thinking this is worse with Windows CE...

[TheKidWho]

Wow dude man.

Re:Something tells me he orders BigMac at Burger K

[tyrione]

The problem is not that the UI is -completely- different.

It's an UI that is massively the same, just ran through a bulk rename, shuffle parameters order around in function calls and explode/implode some methods / typical sequences.

The UI -could- have been VERY similar, with only minimal differences easy to #ifdef through - the underlying philosophy is. Instead, there was some active effort put in making it totally incompatible, where making it compatible would be easier and more obvious.

A typical case of "an extra week of writing code can save you a hour you'd spend on reading documentation instead."

How the hell do you get listed as Interesting? Interesting to what? A 12 year old?

Defining moment

[OzPeter]

For the me, the defining moment in this rant (where I couldn't take it seriously any more) was when he complained about the $100 developer fee required to get his code running on a real iPhone. I know that other people have sad it before me - if you want to play with Apples ball, you have to play by their rules. So that knowing what the (in this case well known - App approval is different) rules are and then bitching about them comes across as childish.

I'm also tempted to comment on his choice of development hardware (G4) being a bit on the cheapskate side, but I am not familiar with it and don't know how serviceble this older hardware is.

Re:Defining moment

[mswhippingboy]

if you want to play with Apples ball, you have to play by their rules.

I, for one, refuse to play with Apples ball.

Re:Defining moment

[SteeldrivingJon]

"I'm also tempted to comment on his choice of development hardware (G4) being a bit on the cheapskate side, but I am not familiar with it and don't know how serviceble this older hardware is."

He can't be developing the iPod app on a G4 - it's not possible. He must be using a modern Intel Mac. I think he must also have a G4 around, and he built his modified code for it to see how it would perform.

Re:Properly cross-platform code cares not for the

[NNKK]

I haven't actually read TFA

You needn't point out that out, because it's painfully obvious that you know absolutely nothing about Dali Clock, its cross-platform history, or JWZ's own well-documented history and experience.

Educate yourself first, then speak.

http://www.jwz.org/xdaliclock/
http://en.wikipedia.org/wiki/JWZ

That's my fault, not ZooLib's. Check Andy's page!

[MichaelCrawford]

Andy Green of The Electric Magic Company.

He's been developing ZooLib for twenty years, but it has only been Open Source for ten.

Andy is a consultant; whenever he gets a new contract, if ZooLib doesn't already provide some functionality he needs for his gig, he adds it into ZooLib.

As for the website not listing many apps - I'm the webmaster, but not a very diligent one. Most of ZooLib's apps are sold by the various clients that Andy and I have had over the years.

Re:Something tells me he orders BigMac at Burger K

[Anonymous Coward]

"I'm all for criticising the iPhone's genuine faults"

No you're not, you're one of the biggest fanboys going. You couldn't see an iPhone fault if your iPhone blew up in your face.

Which is a possibility I suppose, thanks to Apple's crappy engineers ensuring that has actually happened to some people.

You're one of those idiots who owes a company nothing but would gladly support the DRM, child labour, and other general rapery that the company is heavily involved in simply because their fancy little UI animations give you a hard on.

To give you an example of why you are wrong, take a look at the likes of the .NET compact framework to see that an API for mobile devices doesn't have to be so horrendously different from the desktop API that you have to pretty much re-write large swathes of your application.

If it's already cross-platform, why the grief?

[MichaelCrawford]

I think JWZ's crucial mistake was in expecting the Mac OS X source to just work out of the box on the iPhone. Apple never made that claim. It's the wrong approach to take.

While there are many conceptual similarities between the two operating systems, they are different enough that they really should have been considered separate platforms from the very start.

I've been doing cross-platform development for twenty years. Don't Even Get Me Started.

IPhone vs. Android Review - In Reality

[MogNuts]

You are 100% correct. So let's end the Apple myth. I see all these planted and biased reviews, and I can't take it. They're just garbage and they're feeding the Apple image, which frankly isn't true. I recently used both phones for a month (not 2 days like most reviewers). Let me precede that both are pretty darn good. But the IPhone isn't better. All the good stuff, and that which is moving ideas forward is on Android. Here are my findings as to what is better about each over the other:

IPhone

1. Appearance of "smoothness." Notice I said "appearance." They're both just as quick, it's just that the IPhone has better visual animations in the interim to distract you to make you think that's its immediate. It's really not as quick as you think between actions.

2. Touch screen works the way you think. This feature isn't better, only different. Once you get used to either phone, it doesn't matter. With the IPhone, when you press something, adjusts to where you really think you're pointing, whereas in Android, it's where your finger actually rests and makes contact with the capacitive screen.

Android

1. Probably the most amazing and useful feature ever in a phone--auto synchronization between Gmail, Google calendar, contacts, and photos. Yes blah blah Mobile Me. Well Google is free--Apple is $100/yr. And please, the functionality and features of Gmail and Google calendar absolutely crap on the lame excuse of the Apple offerings. Don't even try to argue this one.

2. Free turn-by-turn GPS. Killer feature here. Saves you like $15/mo for navigation. That's big. And I could never justify 15/mo when I could navigate myself with Mapquest. Well now that I use it, it's amazing, and I still can't justify the 15/mo for it, but I can justify getting an Android phone over Apple for it.

3. Free tethering. This feature is huge. You're paying for a data plan either way, but at least with Android you don't need to shell out another 60 per month for a wireless cell service just because Apple says "Because I say so."

4. Higher resolution. Makes text to much more readable and the difference in image quality is like night and day between the two.

5. The ability to use it as a mass storage device, with a removable Micro SD card. Droid has 16gb worth to store.

6. User-replaceable battery. No $60 rip-off price and driving to an Apple store to get a new battery installed. And tell me this, one day your IPhone will freeze. Not if, but when (all software does). Do you want to be out a few days just to gain use of your phone when it won't restart via software? When with Android, all you have to do is pull the battery out? This one is a scary demerit for Apple.

7. I can install what I want. I'm not told I can't use tethering. Killer features then the IPhone doesn't have: tethering and VoIP (and I mean on a cell network, NOT over wifi--wifi is useless if you're out of your house, and NO I'm not going to travel to Starbucks to use VoIP, no matter how plentiful they are).

8. Finally, the last game changer and killer feature Android has over the competition: voice to text translation, in all fields (especially text messages). I've never seen a voice-to-text program since the early 90s that actually worked well. I can't believe it, but Google's does. I barely even use the keyboard when sending texts anymore.

And to address all the "b-b-but !", no, Jailbreaking is NOT a solution. It just isn't. The average person doesn't know how to do it, the average person technically inclined who actually has a job can't be bothered, and I'm not voiding my warranty or preventing myself from getting updates for it.

As you can see, the baseline of each phone is pretty equal. But the only features that the IPhone excels at are weak. Androids superior features are pretty much game changers. I only hope that at least some people read this to know how the products REALLY compare.

Go ahead now, mod me down into oblivion.

Re:IPhone vs. Android Review - In Reality

[mdwh2]

Indeed - not to mention that there are plenty of other mainstream widely used alternatives too (e.g., Nokia).

Jailbreaking is NOT a solution. It just isn't.

Exactly. It's interesting that it's considered an acceptable workaround for a phone that's meant to "Just Work", and is supposed to be easy to use and good for non-geeks. The irony is that whenever a similar workaround is suggested for another platform, the Iphone fans ridicule it.

Then there's the point that when we get stories about Iphone viruses, people claim it doesn't count because it only affects jailbroken phones - which is it, I wonder?

Re:IPhone vs. Android Review - In Reality

[Anonymous Coward]

Sure, I'll mod you down. Especially because you fail to list a lot of upsides and downsides of both phones, and because you fail to see that your specific needs might not be what the average user needs at all.

Re:IPhone vs. Android Review - In Reality

[Albatrosses]

And please, the functionality and features of Gmail and Google calendar absolutely crap on the lame excuse of the Apple offerings. Don't even try to argue this one

I got about this far, thought about how I use Gmail+GoogleContacts+GoogleCalendar on my iPhone right now (and they work perfectly), and stopped reading.

Nice trolling, though. It was a good try.

Re:IPhone vs. Android Review - In Reality

[jo_ham]

Apple does not stop me tethering, or charge me any money for it. My iPhone had tethering out of the box for free. Don;t blame Apple for a carrier decision. Carriers in the rest of the world are not stuck in the late 90s like the US.

You mentioned tethering twice in two separate bullet points.

You can buy turn by turn navigation for a one off cost from the app store for your iPhone with at least three different apps with no monthly charges.

User replaceable battery - similar to the iPod battery exchange, they just give you a reconditioned phone in exchange for your old one. They come from the refurb department.

Number 6 is just rubbish. You know you can hard-boot the phone right? If it crashes in software (and mine has) you can force restart it without the software running, or while it's frozen. This is the same as removing the battery and replacing it, it;s just done in the phone's base firmware. There's no "scary demerit" for a problem that you are making up.

There are enough points of comparison between the iPhone and Android to work with (and some where Android is better, some where iPhone is better) without you having to make stuff up. Do you work for Fox News when not posting on slashdot?

Re:IPhone vs. Android Review - In Reality

[chriso11]

But I get almost all of that with WebOS (except for the SD card, which is quite nice).

Re:IPhone vs. Android Review - In Reality

[Cid Highwind]

"7. I can install what I want.*"

*Provided that what you want exists for Android (and in some cases your phone's specific flavor of Android), which it probably doesn't.

Re:IPhone vs. Android Review - In Reality

[MogNuts]

It's all there. Android is over 40,000 apps now. Anything of value you can find, go actually look instead of being an armchair quarterback. And no, I don't see the value in 20,000 duplicate fart and flashlight apps that populate the ITunes store.

Re:IPhone vs. Android Review - In Reality

[MogNuts]

1) Blame whomever you want. All the other phones can tether on AT&T. The IPhone can't. Case closed.

2) Care to back it up and mention which apps are these? And with Android I don't have to pay at all. Fail.

3) Are you serious? I spent all that money for a new phone--why would I want a used and abused one to replace it simply for a new battery? Geez, I assumed they just replaced the battery--I didn't know this. This is even worse.

4) If this is true and actually works (the hard-boot), which I doubt (software can always crash--even firmware), I'll give you that one.

Re:IPhone vs. Android Review - In Reality

[MogNuts]

Wasn't aware they integrated it. Doesn't negate the rest of my points.

Re:IPhone vs. Android Review - In Reality

[MogNuts]

I agree. WebOS is a pretty nice darn platform. I just have issue with Apple zealouts and more importantly all the tech media basically labeling it the Jesus-phone all the time, when superior alternatives exist. It's just who I am--I hate to see people duped so blatantly.

"I don't hate Apple products, I hate its users."

Re:IPhone vs. Android Review - In Reality

[FuckingNickName]

Re (3), there's no conception of ownership and longevity in the Apple model. The objects I've kept over the years have proven themselves to be of reliable build (including at component level!), received excellent care from me, been occasionally tweaked in nontrivial ways to my liking, etc. If someone said to me, "Well, your DVD drive is broke... I'll have to give you a whole other machine" I'd laugh out loud.

Re:IPhone vs. Android Review - In Reality

[jo_ham]

If your DVD drive breaks in your Mac, they just replace the drive.

Or you HD, or LCD panel, or any component.

The reason the battery exchange exists for the iPod is that it's quick to just send out a new iPod/iPhone while yours returns to them in the mail in a prepaid box that they send you. It's convenience. You can get your own iPhone changed it you like - it just takes a little longer since you have to send it in, have them swap the battery and send it back, unless you want to buy a third party iPhone battery and change it yourself - it does have a regular friction fit connector on the PCB, it's not soldered in).

Re:IPhone vs. Android Review - In Reality

[jo_ham]

"Case closed"? - I told you, my iPhone has tethering for free out of the box. It is a carrier decision, not an Apple decision. AT&T chose not to allow it for free on the iPhone - take it up with them. Apple didn't tell them to have that policy, AT&T are just being crap there.

Turn by turn apps? I don't know if I can link to the US itunes store, but they include TomTom, one from Garmin and one from another supplier. Here is the UK iTunes Store:
(in fact, in the App Store quick links on the home page the 4th one down is "Turn by Turn Navigation"). There are several apps of varied price, including TomTom, Navigon, CoPilot, Navmii etc. I can't link directly to the store, but they are there.

For 3, you don't have to take the new phone - you can have them send you back your original phone, it just takes longer since they have to swap out the battery for you. If you go for the exchange they send you a new or a refurb phone (and the refurbs are as new, and get more extensive QA than new phones) while your phone goes back to them in a pre-paid box. It's a convenience thing. You may even get a newer and better condition phone than your original (but in the same model type - 3G, 3GS etc).

The hard boot does work, I have used it a few times. The iPhone OS software *does* crash sometimes, and does do odd crap that requires a forced boot. I also had a failed update on the phone that left it in a bricked state (iTunes not seeing it, phone not usable) but I was able to force restart it this way and enable iTunes to begin the update again from scratch.

Re:IPhone vs. Android Review - In Reality

[jo_ham]

As an update to my above reply.

The free Turn by Turn from Google may in fact be a major selling point for an Android phone being a future purchase of mine - I wouldn't be surprised if we *didn't* see it on the iPhone for that very reason. Until then, I had not seen anything compelling enough to make me consider switching, this may be it. The TomTom app, that I was so desperately waiting for (and willing to buy!) was demoed at an Apple keynote, and when finally released was *absurdly* overpriced - might as well have bought a standalone sat nav device, so as yet I have not bought the app for my iPhone.

Re:IPhone vs. Android Review - In Reality

[FuckingNickName]

Quick is my being able to replace the battery in 10 seconds by swapping out. Tolerable is going into a shop and their taking 10 minutes to swap it out using a special tool. Last resort is sending my equipment off to be fixed within 48 hours. There is nothing less convenient than having to wait for the post then having to backup and restore including all modifications to a new machine which will have different characteristics.

Do you have a link for the "replace the battery in your own phone" service?

Re:IPhone vs. Android Review - In Reality

[jo_ham]

Yes, it's "don't buy a device with a built in battery.com"

If the lack of the battery door (and the reduced capacity or increased physical size of the device) is a dealbreaker for you, then it's not the right phone for you.

The convenience of the built in battery with the much smaller size and bigger capacity per size (I realise there are longer batteries) outweighs the fact that when it does need replacing I need to go to an Apple store and swap it out, or send it off for a few days for replacement.

YMMV.

Re:IPhone vs. Android Review - In Reality

[MogNuts]

I'm not going to argue about tethering. The IPhone can't do it, unless you Jailbreak it. And I spoke already about Jailbreaking.

As for nav apps, I just looked. TomTom is $70!!! Holy crap. Nominal fee my butt. Which brings me back to my original premise about Google providing *free* nav.

For 3, are you reading what you are writing? You have to wait a few days for them to *mail* you your phone to get a simply battery? It keep getting worse! You mean I can't get it done that day at the store? And to your refurb point, no, I don't trust a refurb *anything* to be better than new, or a device I take care of and keep in good condition. Just like those "certified pre-owned" cars right off lease, have you seen what people do to leases? (Hint: put regular in a car that requires super for the *life* of the car. Wow).

Re:IPhone vs. Android Review - In Reality

[jo_ham]

You can get it done in the store if you like - but the mail in option is also there. They'll send you a prepay box if you don;t have a store near you or you don;t want to make the trip. The options are there, but it is clearly a more compromised setup than a user-removable battery - it's the compromise you pay for the smaller form factor.

The iPhone can't tether (without fees) *in the US* - everywhere else the iPhone is sold, it does. I can tether with mine *right now* and have been able to since I bought it with no fees and no jailbreaking. So, saying that "it cannot tether" is simply false.

The TomTom app is crazily expensive - I was so looking forward to it being released after the demo during the keynote, but then (after a much longer wait that suggested) they revealed the price, and the cost of the in-car mount, which is a further £90. The price for the app + car mount (which you really need since it charges your phone) is £150 in the UK, which is just stupid - it's more expensive than an actual TomTom satnav device and has drawn some serious ire from users expecting it to be more sensibly priced.

There are other turn by turn apps on the iPhone that are much cheaper - TomTom is the most expensive by far, but no free ones. The google one on Android looks excellent, and is the first compelling app I have seen that is making me consider a change of phone when my contract is up. It's an excellent selling point, which is why we're unlikely to see it on the iPhone from Google.

Incidentally, Apple refurbs are a little different - they are all either product returns, repaired units or unsold stock. Every refurb goes through an intensive test and QA process - they are better tested and checked than their new stock (the bulk of which are not tested before sale). You are not limited to taking a refurb though, you can keep your original phone, but have to deal with the extra time it takes for them to send it back to you, or have to wait in store/collect later depending on hours. Apple's refurbs are not "rental cars" - anything that isn't as good as new is simply discarded.

(also, in the UK there is no "regular" and "super" - only super)

JWZ is an important figure in the history of

[aussersterne]

web (specifically, web browser) development, with Major (capital M) contributions to the mozilla/netscape/firefox ecosystem since before mozilla/firefox existed as projects in their own right (going all the way back to Netscape 1.0), as well as fingers in things like Emacs and popular X applications.

Re:JWZ is an important figure in the history of

[OzPeter]

And why should we care?

web (specifically, web browser) development, with Major (capital M) contributions to the mozilla/netscape/firefox ecosystem since before mozilla/firefox existed as projects in their own right (going all the way back to Netscape 1.0), as well as fingers in things like Emacs and popular X applications.

Yes, we know he is a smart cookie, but that still doesn't answer the OPs question.

After looking at the webpage of the app in question (as posted by someone else here - I had never heard of the app before) all I see is some nostalgic clock App that seems to be being forced into a cross-platform test case where it doesn't really fit, and then complaining about the process. And then gratuitously throwing in some rant about the $100 developer cost. Yet nowhere have I seen any claims that a) OS-X and iPhone OS are meant to be *cross-platform* at all, and b) that the developer registration cost has ever been anything but $100. All I have seen is someone who disagrees with Apples development process for OS-X and the iPhone and does so in the same way as a multitude of un-notworthy people have done before.

So to me, none of this is really newsworthy and I am also left with the OPs question being unanswered.

Re:JWZ is an important figure in the history of

[Anonymous Coward]

In other words, over the last 10 years he hasn't done anything but whine about how awful technology has become.

Re:JWZ is an important figure in the history of

[Anonymous Coward]

Lurk Moar!!

You've never heard of all the cool JWZ screensavers.....uh...ok. Apparently you are new to this.

JWZ didn't need a URL; in the day it was just "about:jwz" and the netscape spinner turned into a compass.

As he mentions in his blog, he sells beer now due to the utter stupidity of all that lurks in computerdom.

He is noteworthy because people do follow him, what he says does matter because this isn't his first slashdotting.

It's a social thing

Re:JWZ is an important figure in the history of

[Dunkirk]

He's a well-above-average-skill-level hacker. Maybe one of the best. To me, this qualifies him to comment on anything that's a non-trivial coding exercise, and anything around it. News for nerds, and all that.

Re:Something tells me he orders BigMac at Burger K

[jo_ham]

Wow, there's a big jump from "likes Apple" to "supports child rape" - I can see why you posted AC.

For the record, I hate that the built in calendar app on the iPhone doesn't carry across the ToDo lost from iCal, only the event calendars, and that I have to use a third party app to sync my ToDo list.

I also dislike the slight pause the phone has sometimes when I answer it and it says has picked up, but there's no connection for a second or so. I'm not sure if this is the network or the phone, but it's probably the phone.

It also needs a way to lock the screen orientation by default without the use of a third party app.

The app store needs a checkbox update system so I can choose if I want to update all but one app (rather than either updating everything or updating one at a time).

Sometimes if you take a picture in landscape with the phone "upside down" (ie, tiled over one way rather than the other from vertical) the tilt sensor gets confused about which way up the photo should be and you end up having to gingerly hold it to stop it spinning all over the place - the photo app needs a way to lock rotation, and to be able to edit the "up" direction on images you have taken.

I'd also like it to keep reminding me I have an unread message via vibrate/tone if I don;t unlock the screen, rather than just remind me once.

I don't support DRM and have spoken against it in the past.

While we're on the subject of Apple faults, the Finder really needs some love, and Mail.app really needs to have a more graceful fail method if a mailserver rejects authentication rather than just continually prompting for the password with no indication of failure.

Oh, but I'm sorry, don't let my actual beliefs and opinions get in the way of your blind AC hate of Apple and preconceived ideas about me. It's a little bit pathetic and hilarious, but I feel compelled to point out the inaccuracy.

So, we were talking about how Apple's API for a fixed resolution touchscreen was different to the one for a variable resolution mouse+keyboard based GUI, and how some whining guy on a blog is complaining that Apple didn't make it as easy as "1. recompile app, 2. ????? 3.Publish on app store 4. Profit".

Re:Something tells me he orders BigMac at Burger K

[elrous0]

IF he thinks that's hard, he should try using the Java GUI on an Android app sometime.

it's the future now!

[agentultra]

"It's 2010, and we're still innovating on how you pass color components around. Seriously?"

It's 2010, and we're still using cars? Where's my jetpack dangnabbit!?

Re:Want Real Cross-Platform? Try ZooLib!

[Anonymous Coward]

Of course, Apple's new policy (which everyone assumes is aimed at Flash, which God Help Us is the new Java) is to ban any app from their store not written using Apple's own iPhone development toolkit, so this would theoretically be disallowed.

Where were you when the iPhone launched?

[SuperKendall]

Can we all please stop making apps, and start making web-apps?

That was tried at launch, remember? People rejected the concept on a massive scale. Were you calling for Apple not to release and SDK back then?

Mods, if you disagree, post a response.

[aristotle-dude]

The parent is not flamebait. It is an accurate description of what issues exists with all of MSFT's platforms. Windows 7 is an attempt to depart from this bloat but I'm afraid that they are throwing out the baby with the bath water.

If you disagree, post a rebuttal instead of wasting your mod points.

I speak as someone who develops for windows platforms on a daily basis at work and yet I choose to run a mac at home and I own an iPhone. Some of my co-workers that work in QA also own macs at home.

Model, View, Controller..

[Roogna]

There's a reason Apple preaches up and down about a MVC paradigm when working with Objective-C and Cocoa. It -does- make this kind of port much simpler. If the code was divided up properly in the first place, then the Model and the Controller parts would be basically just a recompile for the iPhone from MacOS X. The view would have to be redone, but as far as MacOS X -> iPhone goes that should be almost entirely done in Interface Builder.

Now granted the app in question is a very old app. But by virtue of that, given that it displays a UI, that's going to cause more work. But as someone above said, "It's like bitching against linux when trying to build your Qt code against gtk". The VIEW portion of the app is being done for different devices, and AppKit isn't exactly lean enough for embedded programming.

So all I got out of the article is that the guy maintains an old messy code base, which he usually has to fork to port to new platforms but for some weird reason he thought because the -kernel- and low level api's are the same between these two platforms, that it would just compile and run...

Brilliant.

Re:Model, View, Controller..

[julesh]

Something tells me MVC may be overkill for the app in question.

Model: The current time. May be conveniently stored in a single 64-bit int.
Controller: Er, well, there is none. The application only "views".
View: Ah, yes. Basically the entire application.

Re:Model, View, Controller..

[Roogna]

Model: The current time.
Controller: Converts the model into a "bitmap" display of a clock, this is entirely portable because it's just empty memory
View: Blits said bitmap to the screen. This piece has always varied between OS's and platforms and is something that Apple's own documentation says will need changes between iPhone OS and MacOS X. Just as it would need changes between Qt and GTK. Or X11 and Windows. There's been plenty of abstraction layers build over the years to handle this piece, but they handle it by presenting a single high level layer and handling all the low level differences internally. What the article is about, is that surprise surprise, those low level layers for blitting are different between 2 different (Even if similar) platforms.

Re:Model, View, Controller..

[Abcd1234]

Wow, that is entirely the wrong breakdown, here. The controller should *never* perform presentation activities. Ever. What happens if you decide you want to change to a vector-based display? Or make it digital? Or, heck, just change the colours?

No, the GP was right. Full MVC is overkill, here, as there's no use interaction, and thus no controller necessary. OTOH, a model would certainly have it's uses (transmuting UTC to time zones, breaking time down to YMDhms components, etc, could all be done in the model). But the vast bulk of any "render-heavy" application is obviously gonna be in the view.

Work offline

[tepples]

How many websites make their source code available?

HTML5 includes support for apps that can work offline. But this requires that the entire logic of the app be written in JavaScript and that the JavaScript source code be sent to the end user's browser.

JWZ is an idiot

[Eunuchswear]

I can't actually run it on my phone, because I haven't gotten over my righteous indignation at the idea that I'm supposed to tithe $100 to Captain Steve before I'm allowed to test out the program I wrote on the phone that I bought. I imagine I could manage it if I jailbroke my phone first, but the last time I did that it destabilized it a lot and I had to re-install.

"Righteous indignation"? You didn't know this before you bought the phone?

Getting it working now and fast later

[tepples]

What would you prefer - an API that makes it clear what the optimal code path is, or a way that lets you save a few lines, but results in poorer performance?

I'd prefer both: a low-level API for the fastest performance, and a wrapper library for a more gentle introduction to the API. Haven't you heard of the maxim about getting it working now and fast later?

Re:Getting it working now and fast later

[Svartalf]

And several people have gladly provided something that will do that very thing. It's tempting to ask the ARB to accept it as a RI for this sort of thing as they still kinda need it.

Re:Getting it working now and fast later

[mdwh2]

Not if you have to rewrite the engine to do it, or unlearn lots of bad habits I'd picked up when learning it, no.

Re:Properly cross-platform code cares not for the

[M. Baranczak]

This is good advice for most programs - but we're talking about an animated clock. There's nothing there but UI code.

"Linux is only free if your time has no value"

[Anonymous Coward]

He originated that brilliantly insightful quote, leading the wave of Linux users who dumped that piece of shit operating system for OS X, which *just works*. Thank god for JWZ!

He was the first to vocalize what we all knew, that "free" software is not really worth the time and effort put into it. "Open Source" and "free software" are an outdated and dying development model that really does not reflect the way a real developer such as JWZ works. This is why the only people still using Linux are those that have bought into the Richard Stallman religion known as "freetardism".

Re:Something tells me he orders BigMac at Burger K

[ClosedSource]

I was forced once to develop a Windows app using Ada. Trying to develop an application on Android based on standard Java GUI libraries sounds about equally wise.

It's your choice, devs...

[mswhippingboy]

The way I see it, Apple is perfectly within their rights to put whatever restrictions they choose on who/what/how to develop for the iPhad platform.
Developers are free to choose to write for whatever platform they choose.
It boils down to these items:
Do you want a large, potentially lucrative market and don't mind all the restrictions and cost associated with developing for iPhad (i.e. $99 fee, Apple hardware/software only, Objective-C only, app acceptance subject to Apple's whim, **frequent updates as each new OS release could potentially break your app, etc.), then by all means develop for the iPhad platform.
Do you want a platform for which you can choose your development hardware, software (that is available free), no restrictions on what or how you develop, Java, C++ or C languages supported, and are willing to try and market your app in smaller, more chaotic distribution channels, then go ahead and develop for the Android platform.
I would add Windows mobile development to this list, but I haven't done any development work for Windows mobile so I withhold any comments on where it fits. However, I would assume that it probably fits somewhere in between the two afore-mentioned platforms.

I've already made my choice.


**this one is bound to invoke the wrath of applemmings:

frequent updates as each new OS release could potentially break your app

I'm sorry if this invokes ire, but this is absolutely true. 99% of all updates I've received for the apps that I and my family's 4 other iPhones have installed have been updates to support the features of each subsequent OS release, and in most cases to fix them so they would even work with the new release.

It's more of a business problem

[ClosedSource]

The problem is that browsers aren't completely the same and they probably never will be because every browser maker wants to differentiate their product.

If we could actually get all the parties to agree to implement a standard, we could just have a desktop standard API that includes web services. Then we wouldn't have to carry the browser model baggage.

But that's not going to happen and neither is the browser-based utopia.

Key word is 'selling'

[huckamania]

EMACS is great and you could post a long list of accolades, but 'top selling' wouldn't be one of them.

cruft

[sbierwagen]

I like the entirely pointless twitter link in the summary. Hey, here's what one guy thinks about iPhone development, but first, have an entirely irrelevant and content-free quip from some other guy! Yeah!

Re:Want Real Cross-Platform? Try ZooLib!

[Anonymous Coward]

Hrm... It looks like ZooLib hasn't moved forward in some time. I'd looked at it a while back, but there are no menus under Linux, so ended up passing on it for wxWidgets instead.

I had a quick look at it today. No screenshots on the site, and the x86 samples refused to unzip.

Nice Strawman

[mikestew]

"Dismantles any claim..."? Here's a hint: if any such claim has been made by Apple, I've yet to see it in any docs or presentation.

Yes, Cocoa and Cocoa Touch are a lot alike in language and conventions. I can even get a lot of properly-structured code to work just fine between the two platforms. But at no point have I been deluded into thinking that a simple recompile is all that's needed to go from one to the other.

The rest just sounds like the ranting of a bitter old man who is reminded why programming isn't really for him anymore. (This coming from a fellow bitter old man who oddly still can't stay away from the compiler.)

JWZ calls "X Window System" "X Windows"... wtf!?

[Anonymous Coward]

"In 1991, I (Jamie Zawinski) re-implemented it from scratch for X Windows on Unix."

"X Windows"???

Seriously WTF!?

[meta/OT] Slashdot not displaying all comments

[Anonymous Coward]

Looks like this (my) comment in this form is invisible to anyone but me, unless you already know the exact comment URL.

Re:Something tells me he orders BigMac at Burger K

[Abcd1234]

It's an UI

Wow... do you actually say "ooey" when verbally referring to "you-eyes"? Because, that's, like, kinda weird. :)

blah blah blah

[Anonymous Coward]

I have a bitmap. I want to put it on the screen, fast, using two whole colors. And the colors change some times. This should be fucking trivial, right? Oh, ho ho ho.)

You know what? It is fucking trivial. And it is fucking cross platform. Use a CGImageMask. All the CG* code I've written works on iPhone and OS X with no changes (other than OS X being flipped).

Who is this guy?

[fm6]

My first encounter with JWZ was through the config files for Netscape 1.0. I was trying to make the software use the keyboard the way I was used to on Linux. The comments in the config files should have been an aid to that. Instead, I found a lot of angry rants signed "JWZ". Some lectured me that the usual way to configure the keyboard was stupid. Other were poorly-informed flames aimed at various UNIX workstations vendors. Very little actual technical info. I conceived a serious dislike for the dude then and there.

So I have to ask, What did JWZ ever actually accomplish? There must be something. (Working at Netscape long enough to retire on his share of the AOL buyout doesn't count.) If not, why does anybody pay attention to him?

Re:Want Real Cross-Platform? Try ZooLib!

[ytpete]

I think Apple's proposed new licensing terms would ban this framework: "Applications that link to Documented APIs through ... [a] compatibility layer or tool are prohibited."

They basically want to make it impossible to write iPhone apps that share UI code with any other platform (including, or maybe especially, competing mobile devices where having very a similar UI in your app is perfectly sensible).

Stop making web-apps, start making web-apps

[mjwx]

For crying out loud, lose the application fanboysim (Parent and Grand Parent). Both web applications and desktop applications have their uses.

A web app is good for a front end that is consistent for anyone who uses it and is available from anywhere. I have a few web apps installed internally and they are great for centralised control (updates, database) and can be used from anywhere.

Desktop applications are powerful and generally easier to use as they aren't constrained by mark-up languages (XML, HTML). But they are more difficult to manage (your computer may be fine, talk to me when you have 250 or even 100 with no hardware standard) and generally have more problems then web apps (.net version, doesn't work with IE8, relies on IE6 hacks, forget about Linux and Mac). Licensing is also more of an issue.

Lets look at mapping, A WMS (Web Mapping Service) like Google Maps is good for everyone to find information but if you've ever tried doing some editing in Google Maps it's a real pain. So I do editing in ArcGIS (or Google Earth pro) and upload the files into the WMS so everyone can access the information. This way I don't have to give everyone a copy of ArcGIS in order to allow them to get data out of maps.

Moral of the story, evaluate your needs and deploy a web application where it is needed and a desktop application where it is needed.

Re:That's my fault, not ZooLib's. Check Andy's pag

[mzs]

I have never heard of zoolib before, does it support printing in a platform independent manner? That is a biggie for me.