It's sloppy engineering and sloppy user experience.While it maintains a single code base (good for the developer) it has a poor user experience (bad for the people who actually pay for it) and it installs unnecessary bloatware (Mono) which will most likely only be used by this product but takes up valuable disk space and risks compatibility problems with other software on the Mac.

Sloppy user experience, probably, but sloppy engineering? Bullcrap. It only makes sense to write a native client for Mac if there is enough of a market to justify development costs and if Reikan has the resources to maintain two codebases.

Mono taking up valuable disk space? This is indeed 2013 and not 1993... disk space is cheap, the size of mono is insignificant. And Mono will not give compatibility problems for any other software not using Mono.

I would prefer a native app yes, but I would also prefer a Mono app instead of no app at all.

I have just downloaded the Mac version of FoCal Pro. It works absolutely fine with my new 5D III plugged into a MacBook Pro - I updated the Canon EOS and DPP software first. I used FoCal under completely crappy conditions of poor light, shaky floorboards, a cheap tripod and poorly centred on target and with the difficult task of a 600mm lens. 10 measurements gave an adjustment of 5.7±0.6. The classical sloping ruler method gave me 6, and visual analysis of iso 12233 images gave me the sharpest at 6.

As it worked correctly under those bad conditions, I am going to get a decent tripod etc and steam through doing 20 lens combinations on the 7D and 5DIII. For the long white lenses, I am going to get the target printed on much larger paper as it is a bit silly having a tiny A4 target 15-20 metres away.

For these big white lenses, I am going to get the target printed on much larger paper as it is a bit silly having a tiny A4 target.

I'm not sure that matters, unless you routinely shoot at very long distances and want to calibrate for that. If you're shooting at 50x the focal length, the A4/letter-sized target will be the same relative size, whether that's 30 m with a 600mm lens or 0.8 m with a 16mm lens. The reason 50x focal length is a commonly recommended distance is that beyond that, the AFMA doesn't change much with distance, and the DoF is getting deep enough that a minor focus error is usually unnoticeable.

I think I understand what the op means. It means we paid 100 bucks for a shoddy/lazy software port.

It's always best to have code run natively- it will just be a better, smoother app, period. Witt that said, having two distinct code bases is a pain in the arse for devs. Someone's going to get the short end of the stick here, and sadly it's us Mac folk.

However to the op- chances are most n the forum are only tech guys as far as camera goes so eh don't really have a clue to what the negatives could be. So in this forum, the argument is a wash, unfortunately.

Lazy port? So you are paying only for the port not the developing of the algorithms to make it work? And how you know it is lazy? How many hours took him?

"Lazy" all depends if the dev went for the easiest option at the expense of how well the app runs in the mac environment. Im not saying either or, thats on them- but native will ALWAYS be better, regardless of any circumstances.

Personally, Im always curious about visual related software not appearing on macs first- osx is still the lead content creation platform for most creatives. Photography, i would think, falls under that realm.

I think I understand what the op means. It means we paid 100 bucks for a shoddy/lazy software port.

It's always best to have code run natively- it will just be a better, smoother app, period. Witt that said, having two distinct code bases is a pain in the arse for devs. Someone's going to get the short end of the stick here, and sadly it's us Mac folk.

However to the op- chances are most n the forum are only tech guys as far as camera goes so eh don't really have a clue to what the negatives could be. So in this forum, the argument is a wash, unfortunately.

Lazy port? So you are paying only for the port not the developing of the algorithms to make it work? And how you know it is lazy? How many hours took him?

"Lazy" all depends if the dev went for the easiest option at the expense of how well the app runs in the mac environment. Im not saying either or, thats on them- but native will ALWAYS be better, regardless of any circumstances.

Personally, Im always curious about visual related software not appearing on macs first- osx is still the lead content creation platform for most creatives. Photography, i would think, falls under that realm.

In recent years a lot of the advantages are falling by the wayside or being equalized. First, basically all Adobe software runs on Windows as well. Second, Final Cut X cause huge disruptions for many people, and they either have not upgraded, or had needed features that hadn't yet been implemented (or weren't going to be), and so they either stuck with the previous version, or jumped ship to Avid which can run on Windows. Third, the Mac Pro's have gone to a somewhat longer refresh cycle, while the big OEMs which you can get machines certified for certain applications have kept up with the new hardware which gives drastically more processing power for similar price, or better value for similar power at generally lower prices. Last, especially with Windows 7 and beyond, many of the big issues such as font handling and rendering are catching up with Apple in many ways, and so Mac no longer has the bigger on-screen rendering advantages that they used to.

A lot of people (from what I've heard) has said Apple seems to be focusing on their iOS devices and the AppStore/iTunes, and paying less and less attention to the Pro users that do serious content creation. After all, it may be high margin, but there are a LOT more users for iOS devices out there and I'm sure they have good margins there despite it being the consumer space, rather than the pro space.

Apple has accepted Mono applications to the App Store, which is as close to "endorsed" as you can get.

I'd just like to add some perspective to this thread if I may — I'm a software developer for Mac by trade (photography is a hobby) so hopefully I can be useful.

Mono is no less "native" than 90% of Mac products out there. A lot of people think "Native" means "Written in Objective-C against the Cocoa framework", but that's just one of the many tools available to make applications for Mac OS — it just happens to be the one Apple provides. However, many of the applications people on this forum will use day-to-day aren't written using these technologies, for example:

Having a common codebase when your application runs on multiple platforms is the best way of doing things, not just because of cost — if you have multiple codebases for multiple platforms, you can guarantee that the core functionality of each version will be slightly different, and you have to spend a lot of time making sure the separate implementations are compatible with each other as well as weeding out more bugs, etc etc.

However, since Mac OS, Windows, and other platforms have very different looking UIs, this normally leads to a sub-optimal product UI-wise, since to make something work on everything, it ends up being a mashed-up compromise. To counter this, products will often have a common "core" while implementing the UI separately for each platform. It is absolutely possible to make an application in Mono that doesn't look "ported", but it takes more effort than using a UI that works on all platforms. And, looking at the software in question, the UI is so simple that it doesn't need extra work.

Edit: To put things in perspective, Adobe products use a common UI layer on both of their platforms. They went full-in and designed their own UI toolkit that works fairly well on both platforms, but can be frustrating to use on a Mac since it doesn't entirely conform with standard Mac behaviours.

Simply put, if this application isn't "native", neither is Office, Photoshop or Lightroom. And, well, they're all damn fine products. Furthermore, I bet if they'd included Mono inside the application package rather than requiring it be installed separately, nobody would have even noticed that this application wasn't "native".

As for Mono being bloated, well, the install size of the runtime is around 300MB. If you look at the size of Apple's libraries you'll find they're a lot larger than that, it's just that they come with the operating system so you don't have to download it.

EvilTed

If you want to install third party libraries that weren't designed for the platform, be my guest.

It's a hack whichever way you look at it.An engineering decision, made my programmers, to keep a common code base never results in the best user experience...

The Apple libraries are also designed and built and tested for the platform, so their interactions with software, hardware and security are known.Third party libraries are never so well integrated.Remember Steve Jobs booting Flash out of OS-X?

No, because that never happened. They simply stopped shipping it with Mac OS releases since by the time the release got to the public the included Flash version was out-of-date. They did the same thing with Java. Flash works just as well on Mac OS as it ever did.

An engineering decision, made my programmers, to keep a common code base never results in the best user experience...

More or less every medium-sized or bigger project that's on more than one platform has a common codebase at some level. It's very similar to multiple car platforms sharing parts, multiple camera platforms sharing parts, etc — it simply doesn't make sense not to do it.

It's a very odd comment to say that engineering decisions made by programmers are bad. Who else should make engineering decisions? In every project I've worked on, decisions to use a common UI have been made my management to keep costs/time/etc down.

If you want to install third party libraries that weren't designed for the platform, be my guest.

Mono on Mac is a re-implementation of .NET using standard Mac OS technologies — a translation layer, if you will, between .NET APIs and "native" technologies. It allows a .NET codebase to use Mac technologies without a complete re-write.

Your basic point, that applications should be written with care and passion for each target platform, is one I agree with. However, blaming the tool used is wrong — you can create beautiful, robust applications on Mac OS with a variety of tools, and Mono is one of them. If an application is crappy on a particular platform, it's because there hasn't been enough effort put into it by the people who made it — it has nothing to do with the tool used.

To awkwardly crowbar a photography analogy in here — a skilled photographer with a 1000D will create far better photographs than an idiot with a 5Dmk3. Sure, the 5D may make it slightly easier to create great photos, but a skilled photographer can create a work of art no matter what tool he has.

Apple has accepted Mono applications to the App Store, which is as close to "endorsed" as you can get.

I'd just like to add some perspective to this thread if I may — I'm a software developer for Mac by trade (photography is a hobby) so hopefully I can be useful.

Mono is no less "native" than 90% of Mac products out there. A lot of people think "Native" means "Written in Objective-C against the Cocoa framework", but that's just one of the many tools available to make applications for Mac OS — it just happens to be the one Apple provides. However, many of the applications people on this forum will use day-to-day aren't written using these technologies, for example:

Having a common codebase when your application runs on multiple platforms is the best way of doing things, not just because of cost — if you have multiple codebases for multiple platforms, you can guarantee that the core functionality of each version will be slightly different, and you have to spend a lot of time making sure the separate implementations are compatible with each other as well as weeding out more bugs, etc etc.

However, since Mac OS, Windows, and other platforms have very different looking UIs, this normally leads to a sub-optimal product UI-wise, since to make something work on everything, it ends up being a mashed-up compromise. To counter this, products will often have a common "core" while implementing the UI separately for each platform. It is absolutely possible to make an application in Mono that doesn't look "ported", but it takes more effort than using a UI that works on all platforms. And, looking at the software in question, the UI is so simple that it doesn't need extra work.

Edit: To put things in perspective, Adobe products use a common UI layer on both of their platforms. They went full-in and designed their own UI toolkit that works fairly well on both platforms, but can be frustrating to use on a Mac since it doesn't entirely conform with standard Mac behaviours.

Simply put, if this application isn't "native", neither is Office, Photoshop or Lightroom. And, well, they're all damn fine products. Furthermore, I bet if they'd included Mono inside the application package rather than requiring it be installed separately, nobody would have even noticed that this application wasn't "native".

As for Mono being bloated, well, the install size of the runtime is around 300MB. If you look at the size of Apple's libraries you'll find they're a lot larger than that, it's just that they come with the operating system so you don't have to download it.

Well said. I'm trying to think of what I could add to this, but I can't really. Except to say that to me, it's pretty obvious that the FoCal guys are NOT UI/UX designers. Which is fine by me, as all that math and algorithms is really the core of what makes it a great product, although I could wish they'd find someone who can help massage the UI into something a bit nicer looking...