A few days after posting my “Where Fools Fear to Tread” blog a third beta release of the iPhone SDK was released and I have to say that it is a much more stable release than the second. I’ve not had any problems at all with this one. In fact, it seems to compile more quickly and launch faster too.

A friend of mine was so lucky to receive their development certificate. Am I in the least bit jealous, YES. With this little electronic signature I would be able to try out the accelerometers and OpenGL 3D work, but hay, in the meantime I’ll just keep working through the APIs.

Doing a few small projects based on the iSDK just to get my head around the touch interface, Core Animation on such a small screen and a few others. The team at Infurious are hoping to have something ready for the launch of Apples AppStore, or shortly afterwards.

I’ll keep you posted.

It has been a few days now since I downloaded the most recent beta build of Apples iPhone SDK. I would love to say how much of a change there has been and how much more stable it feels, but not so.

It has to be said, that when developing using a beta release of anything, it’s best to use a dedicated machine. Well, taking this advice on board, I installed the original iSDK on my main machine and it worked fine, rather limited, but worked.

The latest beta release arrived with much anticipation. Feeling and expecting this version to be just as stable, it went on my main machine. Oops. A large number of basic functions had stopped working. Then the crashes started happening, just couldn’t figure what went wrong. It just got to the point that I have to wipe my hard drive and reinstall Leopard and the original version of the iSDK.

Two hours later and my problem iPhone app now works without any hitches. Now to clean up the code and find a development machine to work on.

‘Perry’ wrote (on the RogueAmoeba blog post “Code Signing and You”):

“…the case for Code Signing on a Mac - in the service of its administrator/owner - is very compelling. In a sense, the Mac is living on borrowed time - viruses and worms and other nasty bit-critters will surely come our way, and going to an all-signed environment is one the most potent weapons we have to keep your systems from being overrun. I realize this capability *could* eventually be abused in various ways, and I trust you’ll all keep Apple honest about it. But it can also be a powerful force *for* you.

Oh, and to put that to rest: I do work for Apple, and I designed and implemented Code Signing in Leopard. If you think it’s going to usher in a black wave of OS fascism, you have every right to blame me - it was, pretty much, my idea.”

Like some, I see code-signing as a necessary neutral. It’s neither good nor evil but it could be used for evil purposes (where evil is really just a shade of ‘not good’).

It’s all about trust again. When we first heard of Intel’s Palladium, there was an uproar. When we heard about processor serial numbers on the Intel platform, there was an uproar (despite the fact they had been quietly present for years on PowerPC).

The other commenters on the blog put forward scenarios where corporations will use this facility for evil and point to Apple’s DRM’ed music (using FairPlay) and also Apple’s odd restrictions within DVD Player.app on Mac OS X as an example of how the company is ‘evil’.

Of course it’s bollocks.

It took FairPlay to get the media owners (record labels) to start to play ball. Now we have DRM-free music available from multiple sources. Similar Apple’s DVD Player is compliant with the law because they want to avoid litigation. You can get round it by using other DVD-playing applications but Apple plays it safe. They’re not interfering with other third party apps.

It may be blind and stupid faith but I know enough people within Apple and I’ve read enough accounts of people working there that I trust them to do the right thing. Individual end users do need help in discovering which applications are bad and which are good and Apple, in order to reduce the amount of legwork required, is bound to have a review process where they solicit information from users of iPhone applications. This will have the dual effect of speeding up the eventual distribution of applications and also making sure there’s a peer review process.

I’d like to hear more from Perry on this debate as individual security on computing devices is important to me from the point of view of working in the IT business. There’s always a considerable difference in working with Macs and PCs - the latter is always slower in my experience (considering that my day job gives me a Core Duo machine running XP and my home machine is a Core Duo machine running Leopard) due to the need to perpetually run AV and firewall software and if not running them, due to the amount of malware that has been picked up.

Not enough people hear the reasons for design decisions and this is an Apple fault. They don’t make individuals publicly known. Every time there has been an outcry, I’ve always managed to speak to someone within Apple and they’ve given me the reasons for this and that. And yeah, in the wake of their spin doctoring I’ve always agreed.

For the average end user there needs to be a helping hand, an additional way to reduce the contact they have with malware. It’s something that will piss off some people who for political reasons want to have 100% access to their devices but I’m confident that the jailbreaking crowd will cater for them adequately.

So how am I meant to deal with the light blue blobs. I can’t ‘edit’ that text in any sensible fashion when what I really want to do is remove the space just after the * character. I end up just typing the whole thing which removes the point of autocomplete.

Cool, I didn’t know you could just grab entire articles from the IntarWeb and publish them wholesale without even giving an attribution link!

That’s what Rixstep has done?

Scott Anguish, one of the nicest guys on the Intarweb is more than a little upset because Rixstep has repeatedly refused to remove his content which has been ripped of wholesale. What’s worse…

Scott writes

My copyright has been violated by his reproduction. Yes, the DMCA would allow me to get it taken down, and I am exploring that route. But given his track record, I see no way to stop him from doing this. He’s published incorrect and horrible stuff about me, Aaron Hillegass, and others, before.

It is imperative (and the reason I temporarily pulled things down) that long-time readers of Stepwise know RIX stole this.. I do not approve of his doing so. His use does not fall under fair-use, or commentary. He’s simple theft.

I’ve worked 13+ years on supporting developers by maintaining Stepwise (which truly is a labor of love) and I don’t want this theft and misrepresentation to damage that effort.

Rixstep gets traffic by stealing content, misrepresenting the opinions of the authors and doing the whole “keeping it real” thing in the face of millions of new Apple converts.

I must say it’s an interesting marketing step, calling Apple’s customers idiot fanboys while trying to flog them a replacement file manager. It really motivates me to buy it.

Scott Anguish is a pillar of the NeXTStep community. Anything that offends him and, in his own words “makes him sick” should motivate everyone interested in the Mac and especially Cocoa.

The title of this blog may take a little explaining.

I was looking to include a Carbon routine within my Cocoa application, but this routine needed to have access to both my instance variables and other Class methods. It is straight forward to use Cocoa commands in your Carbon routine, as long as they’re declared from within the routine itself. You have no access to the object reference “self”. This refers to the object in which your code resides.

In order to achieve this you first need to create a Class method and an instance init method within your Class. Here I have a Class called AppController where my Carbon routine is located. I add the following code;

+ (AppController *) sharedController
{
    return sharedController;
}

- (id) init
{
    self = [super init];
    sharedController = self;

    // Any other initialiser code needed

    return self;
}

Now from within my Carbon routine a new AppController class is created called controller. I can now use this controller class in place of “self”. This gives me access to all my instance variables and methods.

void MyCarbonRoutine
{
    AppController *controller;
    controller = [[AppController alloc] init];
    [controller aCocoaRoutine];

    // Any other coding needed here

    [controller release];
}

Remember to release your controller class before leaving the Carbon routine or you could end up with all sort of problems.

The 7th Ironcoder contest was announced today (for some definition of today - damn those pesky time zones). I think this year I actually feel confident enough to take part, even if I accomplish not very much For those who have no idea what it is, each contest selects a theme and Mac OS X API, then gives you 48 hours (real time) to write an app that has both theme and API centrally featured. Check out the Ironcoder site for more info, or take a look at the entries for Ironcoder 5.