Mountain Lion and Saving Real Studio Projects

We noticed a very disturbing thing over the past couple of weeks in a couple of different Real Studio projects.  Occasionally, we find that changes to code are not getting saved to disk despite what the IDE.

In both instances we had things in the code editor not get saved.  The sequence was this:

  • Open up code editor.
  • Make changes (dirty flag goes on).
  • Save (dirty flag goes off).
  • Close project and then open it back up.
  • Code changes are not saved.

There is a thread on the Real Studio NUG about this very issue and it appears that it might be a Mountain Lion issue.  I wouldn’t necessarily disagree, EXCEPT that I was using Mountain Lion with Real Studio 2012 Release 1 with Mountain Lion and never noticed this issue.  As someone working on projects all day long and using version control format I think I would have noticed it before R2.

Movie of our code loss:


For us the problem seems to occur when using the VCP project format in 2012 Release 2.  That might be spurious data as we use VCP for practically everything and most of our projects are running in R2.  This has happened in both desktop and Web Edition projects.  Only 1 of these projects is being actively used by multiple people.

In one case I did a Save As over the existing VCP files and it appeared to make everything better and I’ve not seen the issue (in that project) since.  I have not tried using Disk Utility to check permissions and other disk errors.

Is it a pure Mountain Lion issue, is it a Real Studio issue, or a combination thereof?  Regardless, this is a very serious issue that the community needs to help figure out.

Have you seen this issue?  Was it using the binary or VCP file format?  Did you do anything to try and fix it?  What and how did that fix work?


As seen in the comments section it appears that Norman from Real Software found the issue we were seeing and has it fixed.  To recap: my bug only manifested itself in 2012 R2 version control format projects.  You had to change source code in the event of a control on a web page and not change any property anywhere else on the page nor any code in any of the methods.  It should be fairly rare to see this bug and we only found it because we hit that exact sequence.

Anyway, good news that it was found and fixed.  I don’t think it’s the same bug as reported in the NUG though it might be distantly related.  Only RS will be able to discover that.

Mountain Lion and GateKeeper

Yesterday Apple announced Mountain Lion and released a Developer Preview. It was announced to world through the press which is very un-Applelike. Welcome to the new Apple. As a developer I like that – less uncertainty.

One of the major new features in Mountain Lion is called GateKeeper and I won’t attempt to butcher the explanation. I’ll let the fine folks from Panic tell you via their blog post at Come back when you’ve read it.

I think this is a very good thing from a developer standpoint. GateKeeper seems to be a much wanted middle ground that we’ve been waiting for. It seems to give the best of both worlds for both casual and power users (and most that are in the middle).  Security shouldn’t be so painful that mere mortals (and the average developer) should be punished.

Mountain Lion also integrates iCloud into the OS in a big way. A troubling thing, though, is that to use iCloud services you must be in the App Store (either iOS or Mac). That limits my options as a developer. If I want to make iCloud part of my application then I am forced to sell it through an Apple store.

I know plenty of Mac developers that have no desire or intention of putting their apps into the Mac App Store because they don’t want to pay Apple 30% off the top. Some also dislike Apple’s ‘walled garden’ approach. It feels as if Apple is punishing us by cutting off access to iCloud.

Most of the readers of this blog use Real Studio and many are concerned with non-Mac platforms in addition to Mac OS X. I don’t know the answer to these questions: Can we currently include iCloud services in our Windows builds? And will this change for the Mountain Lion release?

Does the move to GateKeeper change the March 1st deadline for SandBoxed Applications sold through the Mac App Store? It seems that this hasn’t been answered yet and I’m not the only one that feels this way. See for more details.

While it’s still too early to have an opinion about Mountain Lion, GateKeeper and iCloud integration are both exciting and mysterious at the same time. I’m hoping the new Apple does a better job of telling developers what our options are.


Lion is a Mixed Bag

I’ve been a Mac user since 1986 and have used a Mac consistently ever since despite many years as an electrical engineer (where DOS and Windows was the norm).  I think I’ve used every Mac operating system since System 5.  I’m also a developer.  I straddle the world of user and power user.  I’m not a newbie but yet I don’t consider myself a Unix power user either.

I’ve had Lion installed for about 3 weeks now.  There are some things I like about Lion and more that I don’t like.

Things That I Like About Lion

Versions:  Being able to see edits in time has already saved me some grief when it comes to editing documents in Pages.  I accidentally opened the wrong document (similar but not the same) for a course outline and started typing away.  I realized after about 30 minutes of editing that this was the wrong one and looked at the old versions and quickly reverted.  See below why I don’t like Auto Save though.

Airdrop:  It’s simple and to the point.  This is how file transfers between occasional machines should work.  It’s not quite as convenient for computers that are already on the network though as it you have to be running AirDrop and approve all transfers.  I did have a problem with two Lion computers transferring zero length files but I don’t know if it’s been fixed in the update that came out this week.

Mail:  The 3 pane interface works for me.  It also keeps track of my conversations and organizes them effectively and reduces the redundant information.  This should have been done a long time ago.

The Price:  At $29 a computer it’s cheap.  The fact that all your computers on your network (using the same Apple ID of course) can get it too is just icing on the cake.

iChat:  Conversations are now unified into a tabbed window rather than each conversation being in a separate window.  For video chats it’s using FaceTime whether you realize it or not.

Preview:  Being able to add a signature to a PDF document has caused me no end of grief in the past several years even though I have a utility to do it.  Now, I don’t have to worry about it.

Auto Correct:  I know some people are bagging on it, but for the most part it works for me.  It’s not perfect but it warns you, visually, when it makes a correction.

Things That Don’t Bug Me But I Don’t Care About Either:

Natural Scrolling:  It took me maybe two days to get used to it.  Sure, I still go the opposite direction at times – get over it – it’s just the flick of a finger.

Full Screen Apps:  Meh.  For the few times that I want the app to take over my entire screen it’s okay but this feature seems to be aimed at 13″ laptop users.

Things I Hate About Lion

The UI elements:  Disabled controls are gray.  Enabled controls are gray.  Sure, they’re different shades of gray, but really?  Is black such a bad thing?  I think this is my number one pet peeve in Lion.

Mail Enabled Buttons:



Mail Disabled Buttons:



Overlay Scrollbars:  Again, another UI element that I think should visible all the time on my big assed 27″ monitor.  There is a preferences setting for it, by the way, but it seems out of place and not like the rest of Mac OS X.

Resume (i.e. Auto Open):  I’ve tried this a few times but I hate it more than I like it.  What I really want is to set this PER application – not system wide.  I don’t want this on Text Edit but I DO want it on Pages.  I don’t want it on my database editor, but I do want it on my development software.

Auto Save:  The apps that are actively using it (Text Edit, Pages, Numbers, etc) I find that I really don’t like it.  Why?  Because I create temporary documents all the time and when I quit the app I want them gone.  Isn’t that what the Save Prompt is for?  This is in direct contrast to Versions above.

iCal:  Really, Apple?  Faux Leather?  Otherwise it’s functional.  The changes to how to create an event on your calendar uses natural language (like Lunch with Carol at 12 PM automatically adds it to the calendar with the appropriate time).

Hiding of Library Directories:  I understand why they did this – most people really shouldn’t be mucking around in Library folders – but it’s more hassle than it’s worth, in my opinion.  Getting into the preferences folder is pretty common (and that happens to be in the Libraries directory).  It’s relatively easy to work around, but now I have to figure out if my users are smart enough to figure it out for themselves or if I have to handhold them through that process too.

Things That I Find Useless:

Launchpad:  Played with it and found that I already have the apps organized in the way I want either in the doc or in Stacks on the right side of my dock.  I suspect that people coming from iOS love this feature.

Things That Are in Snow Leopard and Lion that I Love:

Mac App Store:  If you’re not using it yet you should.  This is the most convenient way to find and purchase apps for your Mac.  The fact that you can then install it on all machines in your house (using the same Apple ID) is VERY convenient.  No more hassling with serial numbers or if, for whatever reason, you need to install old apps again, the Mac App Store can install them all at one time.


There’s a lot of other changes in Lion too.  I recommend taking a look at the 250+ features page at Apple at

I find myself torn between the past and the future.  I’m a long-time Mac user so I’m no newbie and perhaps that’s why I’m not thrilled with Lion.  Despite some big improvements I find most of the major changes to be a dumbing down of the OS for people that are coming from iOS.  That’s not necessarily a bad thing but I’m not sure it’s a good thing either.

What’s most disturbing is the horrible User Interface changes in Lion.  For a company that prides itself in making great UI I think most of it fails on multiple levels.  Visual cues are the first thing that need to be clear and obvious and for that they’ve failed in my book.

Should you upgrade?  If you find Leopard or Snow Leopard useful then keep using it – you’ll get Lion when you purchase a new computer.

What do you like or dislike in Lion?

EDIT:  Updated with images from Mail to show difference between enabled and disabled toolbar buttons.

Long Live Cocoa (or is sandboxing killing carbon?)

Real Software posted an article on changes to the Mac App Store.  Starting in November apps submitted to the Mac App Store must be sandboxed.  This is a huge change and currently, according to Real Software, the carbon implementations to accomplish sandboxing are broken.

More information the Apple sandboxing can be found at and I highly recommend you read it.

At the very bottom is a caveats section: apps can’t send AppleEvents from the sandboxed app (though they can receive them).  This seems rather extreme.  If your Mac app can’t send AppleEvents does this mean that Apple is killing AppleScript?  I doubt it, but it does seem to limit the usefulness of the service and I suspect that there will be a workaround.

Apps cannot work with non-bundled projects that reference other files.  Does this mean that services like Kagi and eSellerate will no longer work?

So what does this mean for a vast majority of Real Studio developers?  Not much really – unless you happen to be selling your apps in the Mac App Store.  For you, the changes are important and you’ll need to start compiling for Cocoa.  Cocoa is much improved in Real Studio 2011 R2 than any previous Real Studio release but unfortunately it still not complete.

So the bottom-line is that if you are developing Mac apps and hope to put it in the Mac App Store then you’d better start testing your builds in Cocoa.  While your app may not ship using Cocoa yet, Real Software needs the feedback on what’s not perfect so they can fix it.

It’s a good idea to start using Cocoa now because in November you’ll need it.  Long Live Cocoa!

Will VB6 Apps Continue to Work in Windows 8?

Will VB6 Apps Continue to Work in Windows 8?  That single question has driven more traffic to this website in the past month than nearly any other question.  I believe VB6 still has a very large user base so it’s very pertinent question for many organizations and developers.  Perhaps Real Studio is an option for them, but we’ll get to that at the end of the post.

Visual Basic 6 is 20 years old.  It’s stood the test of time and it while it’s showing its age it still functions and apps written on it still run in Vista and Windows 7.  To its credit, Microsoft has made sure that this venerable product still runs on modern computers.

But the question of Windows 8 compatibility has hit the fan, so to say, in the past month or so with Microsoft saying that apps can be written in html and javascript.  That threw many developers into a tizzy.

I don’t believe for a second that Microsoft is abandoning .NET, Win32 or COM simply because those are the foundation for nearly everything ever written at Microsoft.  It simply doesn’t make sense for Microsoft to move to another set of API’s even if you believe that Microsoft moves to a new technology every now and then to make themselves a moving target.  If anything, I believe that this might simply be a new way to develop apps but not replace anything.

While doing research for this post I ran across an unattributed quote supposedly from a person in Microsoft Support:

“We can’t make an official comment on our Windows 8 plans yet but it would be a likely outcome that VB6 applications will continue to work. “

I believe that statement but it’s not exactly a definitive statement.  The real question, I think, is how bad will it suck?  VB6 apps work in Windows 7 but without some work they look like they’re from the 90’s.  Most app developers I know don’t want their apps to look that dated.

Microsoft has stated that the Visual Basic 6 runtimes will not ship after Window 7.  This presumably means Windows 8 and beyond.  I have heard that Windows 8 will be 64 bit only and that means that the VB6 runtimes will either not work at all or will have to be run in some sort of compatibility layer.  So this means that existing apps MAY work, but only after jumping through hoops to install the runtime libraries and making sure the compatibility is set.

Let’s face it.  VB6 is an old, old development environment.  It was written in an age where computers didn’t have much memory and only one processor.  Threading isn’t impossible, but the few times I tried to get it working in a VB6 app the result was instability and crashes.  Threading is such an important thing in modern applications.

VB6 is object oriented – somewhat.  For the time it was state of the art but since subclassing controls is impossible it makes for interesting workarounds and wrappers.  Frankly it makes life more complicated than it needs to be.

Twenty years ago, VB6 was the cats-meow.  The Macintosh was around but it was considered a toy (I disagree but that’s not the argument) and few cared about it.  Microsoft was pretty much the only game in town.  Linux hadn’t been invented yet and the internet was for a few hard core geeks.

This is where Real Studio starts to look more attractive.  It works the same on Mac, Windows, and Linux.  Web Edition brings some of the same ease of developing desktop apps to the web.  In Real Studio I can subclass controls and objects (for the most part) all day long.  It’s a modern object oriented programming language.  Is it without foibles and inconsistencies?  Certainly not, but it’s way more powerful than VB6 in many ways.  Threading isn’t perfect, but it’s still light years ahead of VB6.

We’ve seen an uptick recently with people asking us to convert their VB6 application to Real Studio.  Our VB6 Analyzer utility (found at has been downloaded a lot recently.  It allows users to scan their VB6 project and sends us a simple report detailing the number of forms, classes, libraries and OCX’s in use and lines of code and some other simple metrics.  It’s no substitute for seeing the whole project but it gives us a nice way to guestimate the costs of rewriting the app in Real Studio.

Notice that I said rewrite the application.  The only thing that Visual Basic and RealBasic have in common is that they have ‘basic’ in the name.  It’s like comparing a computer from twenty years ago to a modern computer.  Real Studio does things so much easier, better, and faster than Visual Basic that it’s really not worth trying to convert it line by line or even form by form.  Believe me we’ve tried – the end result is that you end up spending as much time fixing VB6 code that has a better equivalent in RB than it would be to just rewrite it from scratch.

Is Real Studio a suitable replacement for every app?  The answer is simple:  no.  Real Studio makes a really good cross-platform app, but that doesn’t always mean it will have all of the buzzers and bells available in development environments meant for each platform (grids in Windows come come to mind).

We are Real Studio consultants.  That’s what we do and we’ve been doing it for ten years.  Most of us spent a fair amount of time in Visual Basic before moving to Real Studio.  If you decide to do the transition yourself you will hate it at first because Real Studio is different than VB.  We all went through it and for a while you want Real Studio to be just like Visual Basic – trust me it’s not – and after you stop trying make Real Studio function like VB6 you’ll start to like it and get it.  Transitions are never easy.  For training videos, we have over 30 hours available at plus you could always hire us to come on site for training.

If you have VB6 project you want to transition please drop us a line and we can talk.  If you want to get multiple Real Studio developers looking at your project, make a post at which gets sent out to the Real Studio developers network.

Is Windows 8 the End of VB6 Support?

I was a Visual Basic developer for many years.  Despite the perception that VB 6 made crappy apps, I know of many successful commercial apps that were written in VB6 and, what matters more, is that those apps are still in service.  Despite Microsoft dropping support for VB6 years ago developers were able to limp along and get their apps working in Vista and Windows 7 with few headaches.

Does this change with Windows 8?  I don’t know, but I’m already seeing an uptick in developers that are looking to convert from Visual Basic 6 to Real Studio.  Uncertainty is a bad thing and even the full-time Windows developers I know don’t seem to know what’s going on.  Some of them are even worried that .NET and Silverlight support is up in the air.

The only thing that’s been mentioned for Win8 is JavaScript and HTML5.  No mention of .NET, Silverlight, or even Win32.  It’s very uncharacteristic of Microsoft to be so secretive and up-in-the-air over a future product.  Are they trying to be more Apple-like?  Perhaps that’s why people are freaking out.

Do I think MS is going to drop support for .NET, Silverlight, or even Win32?  Not a chance.  They have way too much invested in each of those to abandon them.  From a corporate standpoint there would be a revolt since almost everyone has invested, heavily, in one or more of those technologies/platforms.

But are Visual Basic 6 apps still safe?  That is a very good question and from the research I’ve done it appears that the VB6 runtime will not be shipped with Win8 though some in the community suspect that a hack will be found before release.  Other comments I’ve seen indicate that Win8 will ship as only 64 bit.  The VB6 runtime is 32bit only so that will mean running in compatibility mode which adds to the possibility of it not working properly for all applications.

Microsoft, at some point, has to kill compatibility.  Visual Basic is an old development environment that doesn’t take advantage of many new technologies.  It’s also not a very good object oriented language – it just wasn’t designed to be that way.  If the MS dev tools of the future are Silverlight, .NET, and JavaScript/HTML5 (does anyone really believe that!?), then it sure seems that VB6 might be on its way out.

So while VB6 apps might work with Win8 using hacks and compatibility mode, I believe developers have every right to be worried.  They’ve invested heavily in VB6 tools and controls and now the (long) honeymoon is over and it’s time to look at alternatives.

If you are only interested in Microsoft then the options are easy with .NET or Silverlight (assuming they aren’t going away).  If you’re thinking of a Mac or Linux version than the options are limited.  You could do Java, but as a long-time Mac user I’m not a big Java fan and try to avoid them because their UI generally isn’t native (I’m a Mac snob, but then most of us are).  Qt is a possibility but it’s not a RAD option either.

I am a little biased but I think Real Studio is a good choice for those coming from Visual Basic.  They are very much alike in how they work though REALbasic is MUCH better at object oriented programming than VB ever was.  It’s newer and is on a regular update schedule.  And, with just a little work, you can easily make apps for Mac, Windows, and Linux that look the same on all three platforms.  And now that Real Studio can make Web Apps there’s a fourth platform that you could potential support (though making a web app involves different controls, editors, etc so it’s not as easy as clicking a checkbox).

Is it a quick and easy conversion?  No.  Don’t trust any conversion program and, from experience, any converter will be just as time consuming (if not slightly worse) as rewriting from scratch.  We’ve found that taking a look at the UI and making it a bit more object oriented to take advantage of the strengths of REALbasic is always worth the investment.  We like to say you’re writing the apps for the next ten years and not only for right now.  So doing the extra work now will pay off for years.

Is Real Studio perfect?  Absolutely not.  It currently is not 64 bit compatible either though I know of many developers that have no issues with running in Windows 7 64 bit.  I do know that 64 bit compatibility is the next big upgrade for Windows after Real Software finishes up on Cocoa builds for the Macintosh side.  If memory serves they are on track for late 2011 64 bit compatibility (though that’s always subject to change).

With Win8 on schedule to be released next year (does anyone really believe that either?), you might need to be proactive and start thinking about the alternatives now.  Waiting until Win8 is released might be too late for your product.  Do you really want to be under the gun from management to get something that works on the CEO’s new shiny Win8 laptop?

If you would like to get a rough estimate on cost to convert from VB6 to Real Studio, we (BKeeney Software) have a VB6 Analyzer Tool for you to download (written in RB of course) that analyzes your project and gives us some metrics on lines of code, controls used, numbers of classes, etc, that help us give you an estimate.  More information can be found at

Lessons Learned The Hard Way #1

This seems like a no brainer, but we’ve been bitten by it and we’ve picked up the pieces of multiple projects from others who haven’t lived by this rule:  If you’re creating a cross platform application, test early and test often on the platform you’re NOT developing on.

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

  • Canvas objects should have Double Buffering turned on
  • Do not erase the background of Canvas and Container Controls
  • Be wary of using Refresh – perhaps Invalidate is a better choice
  • Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?

Spirit Is Calling

BKeeney Software Inc. announces the release of Spirit is Calling, a daily spiritual journal co-authored by Rev. Chris Michaels and Dr. Edward Viljoen.  Spirit is Calling seeks to grow spirituality by encouraging daily journal entries that allow the user to track their spiritual growth over the course of a year. The journal tracks thoughts and reflections on a daily basis and allows the user to return to previous entries at any time.

Spirit is Calling features a perpetual calendar allowing the user to make use of the journal this year and for years to come. In addition, the program can be scheduled to automatically open every day at a scheduled time. Technical features include a full-featured word processor with spell check and the ability to insert graphics into your journal entries.

Many people find journaling to be very powerful.  It’s a way to get their thoughts and feelings out and into the Universe.  That can be a very liberating experience.  To get the most out of it, it does require some daily attention.  From the book:

Lesson Quote:

Daily practice has an advantage over sporadic practice, in that regular attention to your spiritual life builds up a rhythm in your awareness. This rhythm allows deeper insights to emerge that are not possible with a random program. This journal presents one of many possible devotional activities that you might use to establish a regular, daily rhythm of introspection.

To aid in the process of making it habit we added an autostart preference setting so that at a time of your choosing Spirit Is Calling starts automatically.  In the beginning that can be helpful to get into the habit of journaling.

One of the reasons why I created the electronic version of the journal is that I don’t write by hand much any more.  Writing by hand is very slow and somewhat painful for anything of length.  But I can type 80 words a minute (if I don’t care about the mistakes on the first pass) so having a word processor built-in to the journal (with spell checking) makes sense.

Spirit Is Calling’s home page is at

Direct Download Mac OS X:

Direct Download Windows:

If you are looking to try something different in your spiritual practice, please try Spirit Is Calling.  Perhaps the journal will help you define your goal and get you out of your daily trivia.

Inspirational Quote:

In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it. – Robert Heinlein

REAL Studio and PowerPC Support

REAL Software announced yesterday that REAL Studio 2010 Release 4 will no longer be actively supporting the PowerPC (PPC) framework.  This really means that only major bug fixes will be done to the PowerPC framework and nothing new will be added to it.

At the 2005 World Wide Developers conference Apple announced the move to Intel and many people were shocked that they would give up the PowerPC line of chips they spent a decade promoting as being better than their Intel counterparts.  Intel was the future and blah, blah, blah.  Many people said the Reality Distortion Field was on full blast.

In retrospect it seems so clear.  One could certainly argue that Apple’s resurgence is, in part, because of their move to Intel.  With a growth rates in the 30% range in year to year quarterly sales growths it’s not very hard to come to that conclusion either.

It’s been five years.  Most consumers have an Intel based Mac and most businesses will probably be phasing them out in the next couple of years if they haven’t already.  On, only 10% of visitors are running a PPC Mac.  BKeeney Briefs and the ARBP site are both less than 2%.  When 90+% of total visitors to your websites are on Intel it’s safe to say the Intel transition is nearly complete.

The reaction to REAL Software’s announcement has been calm, I think, mainly because no one is shocked by the move.  Most developers are most likely on Intel Macs and I think a vast majority of software buying consumers are on Intel now as well.

Since Cocoa is Intel only and the IDE will eventually be built using Cocoa this presumably means that the IDE will no longer run on PPC machines.  This is probably not a big deal for most REAL Studio developers.

It might be a big deal for developers serving the education market, however.  But since they’ve said they will not remove the PPC build option for several years that market should be relatively safe for the foreseeable future.

Transitions can sometimes be painful.  The fact that Apple pulled off a major transition with very few problems is a testament to their engineering staff.  For companies that feed off of Apple this transition wasn’t always easy and REALbasic had its growing pains.  The transition to Cocoa has been painful but in the long run it will allow REAL Studio to grow with whatever is coming up next for Apple.

What do you think?  Do you still work on a PPC machine to do development?  Do you still serve PPC users?

Visual Studio For the Mac?

Interesting little blurb at about Microsoft presenting at Apple’s World Wide Developer Conference (otherwise known as WWDC) to show off Visual Studio for iPad/iPhone and general Mac OS X development.

Geeze.  How many levels of wrong is this rumor?  You think Apple is going to trust Microsoft with the keys to their iPhone/iPad kingdom?  I don’t think so.  Apple has worked too hard building xCode and Cocoa Touch to let a 3rd party develop for iPhone/iPad.  If this does happen, then Apple might as well give Adobe a call and let them know they can restart their iPhone/iPad programs too.  And we all know where that feud isn’t over yet.

Where this might make sense is desktop applications.  Microsoft, while doing all that work to write Microsoft Office for the Mac in Cocoa, wrote their own Cocoa libraries and other Mac GUI editors and put it into Visual Studio.  Seems like an awful lot of work with minimal gain for Microsoft unless they’ve decided to make a push in REAL Software’s corner.  They certainly have the knowledge and resources to do such a product.

While I don’t think this rumor has legs it does make you think.  No doubt Microsoft is feeling the pinch of developers learning Cocoa which does nothing for Microsoft.  If they developed a cross-platform Visual Studio it stems the bleeding because now developers don’t have an either/or decision to make.  Learning a new development tool and frameworks suck and letting all those Windows developers develop for Mac and Windows using their tool keeps Microsoft in the game.  It doesn’t help them with iPhone/iPad development (now) but in five years who knows.  If it does happen it will generate some serious buzz which is something Microsoft wants (needs?).

What does this do, if true, to our favorite development tools company located in Austin?  I don’t think it would be good news.