Any announcement I might have missed?
Thanks Jean-Paul.
LLVM is being used (For a while now) on XojoScript
LLVM is being used on the iOS Alpha (or that is what I have been told).
LLVM for other platforms is coming.
Wow, that’s amazing. I’d not heard that.
2016
At first I assumed you were teasing but now I’m wondering! You were joking, right? 
Q1 2015 has been the stated estimate since XDC 2014.
“We continue to make progress towards making Xojo capable of producing 64 bit apps. We currently estimate that we will be ready in the first quarter of next year”, said Geoff Perlman a few months ago. http://www.xojo.com/blog/en/2014/06/64-bit-work-continues.php
Geoff also showed an iOS Xojo app back in 2013 …
We know. I was simply saying that Q1 2015 has been talked about all this year. I suspect Greg was either joking or simply pointing out that an estimate is not an announcement. I don’t think Jean-Paul was intending to claim that there was an announcement, though.
Fingers crossed and hope for the best …
I was being facetious. My objection, to the item that I replied to is that Jean-Paul doesn’t work for Xojo. When it comes to estimated timetables, your best bet is to get that information directly from Xojo.
Anwone who is thinking about answering such questions, please refrain and ask for an answer from Xojo. Speculation tends to be taken out of context down the road and the ire comes back to us ten fold.
Unfortunately due to changes in Yosemite (such as at least one framework appearing to be 64-Bit only), I’m rather anxious… Otherwise I’m going to have to think of something to tell my customers as to why they lose functionality when they upgrade to Yosemite.
All I can say is thank God for MS. I have one client that is now having issues with a LOB product where the db is no longer supported - they’re changing their product. I’d hate to have to live up to Apple’s requirements.
Hi Wayne,
After what we go through, I can certainly agree with this sentiment. However I would also like to add, to balance out the comparison, that I love Apple’s toolbox, no other OS has a framework as comprehensive as Apple’s.
We’ve looked at porting several of our successful Mac products to Windows, in nearly every case we’re using technology which only Apple includes and this would involve a lot more hassle for a market we don’t really know.
Here’s some examples:
Core Graphics, their 2D graphics system has far more customization that what we were looking at on Windows, not to mention that CG will open almost every single image format we through at it, opposed to the 4 formats that Windows supports (may be more with Windows 7~8). RAW support is built-in to the Mac OS, meaning we don’t have to worry. On Windows we’d need a RAW converter, either open source or paid products, one I looked at was $10,000 USD!
Core Image; their image processing system, it not only includes 100~ built-in image filters, it’s easy (relatively easy) to create custom ones directly within Xojo. It’s optimized for multi-core processors and GPUs, which means we get hardware acceleration for free, and it operates on 128-Bit floating images. Again, on Windows, we’d have to invest a lot to get a system similar. Core image is also memory optimized, it’s the only way how we could build a 32-Bit application to process HDR images, without the headaches of the 32-Bit memory limitations.
NSSharingService; (which is a moot point because it’s now 64-Bit only) In the past we’d spend weeks on fine tuning a system for sharing images on multiple social media sites, only to have one change their system without informing us, which then takes weeks to get it working again. Apple has handled this for us. When they add a new service, we instant get support for it, without any extra code. For Windows, we’d have to go back to maintaining this nightmare ourselves again.
Notification system; is at the heart of Backup To Go, it’s what allows it to ‘app nap’ and use zero energy, just jump right into action when it needs to. I looked, but didn’t find a similar solution for Windows, which would mean I’d have to write a disk monitoring system, based upon drive polling to see if the disk is connected or not, which is energy inefficient.
So yes, developing for Apple, in constantly trying to keep up with their ever changing rules and guidelines, is frustrating and sometimes downright depressing, even then, developing outstanding applications is much simpler, thanks to Apple’s hard work in building the best toolkit available for developers.
I agree that Apple is always making technological strides and conceptual leaps that can hardly be matched by MS. But the VERY annoying thing is that deprecation mania that they have. The latest one is the 32 bits code that does not work in Yosemite. Why be so cruel to both developers and users ? I can admit that all the software I bought for PowerPC went the way of the dinosaurs with Rosetta, but why force away Intel code, and in the process break applications users had bought in good faith with their hardly earned money ?
Another aggravating habit of Apple is the adventurous use of technologies later dropped without explanations. Such as Multi Master fonts support simply abandoned when OpenType came about. So what are users who created documents with these fonts supposed to do ? Things that cannot be said over television ?
MS on the other hand almost never retires existing APIs and system calls, even undocumented. I have apps that date back to the 90s that still work fine in Windows 8.1 64 bits, like the Office Suite 1998. As a paying customer, I appreciate Microsoft respect for its end users.
As a developer, I concur entirely with Wayne. Having not to constantly jump from one branch to another to keep up is a godsend.
I agree that the Windows world is somewhat less advanced than Apple’s, though. But it is not still either. It sometimes may take a while, but on the long run, Windows tends to catch up.
Not all developments require the admirable edge technology you employ in your apps.
According to the apple docs (Doc Here) the following will become deprecated:
[i]The IOAudioFamily framework
Methods and properties in Game Kit that use player identifier strings
The NSGarbageCollector class (execution support for garbage collection is not affected)
The NS_DEPRECATED_MAC attribute has been added to many previously soft-deprecated AppKit methods. Searching AppKit headers for NS_DEPRECATED_MAC and filtering for 10_10 will yield a list of affected symbols.
And the following removed
AppleShareClientCore
RubyCocoa[/i]
And by deprecated they mean will become removed so stop using it and phase it out of your software ASAP. I think it is a pre-warning so i’m sure it is not sprung on us its just finding out what is going to be deprecated.
No-one should ever be using Garbage Collection!
If you look at Apple’s rapid deprecation model, it has several key benefits.
#1 it improves the stability, security and reliability of the OS, by not having insecure, lousy and poor APIs hanging around.
#2 it increases developer’s earnings from software! You think I’m kidding? The only time I upgraded Photoshop was when it stopped working or became a crash fest with the latest OS update. While my buddy has never upgraded Photoshop since version 7, he’s never had too!
[quote=128573:@Michel Bujardet]
MS on the other hand almost never retires existing APIs and system calls, even undocumented. I have apps that date back to the 90s that still work fine in Windows 8.1 64 bits, like the Office Suite 1998. As a paying customer, I appreciate Microsoft respect for its end users. [/quote]
Some of those “never deprecate or remove old functionality” are exactly what has made Windows so vulnerable to all kinds of malware over the years.
Some balance in between MS "never deprecate anything and Apple’s “kill anything not new” would be nice 
In progress
[quote=128607:@Sam Rowlands]
If you look at Apple’s rapid deprecation model, it has several key benefits.
#2 it increases developer’s earnings from software! [/quote]
And I appreciate that very much 
[quote=128622:@Norman Palardy]Some of those “never deprecate or remove old functionality” are exactly what has made Windows so vulnerable to all kinds of malware over the years.
Some balance in between MS "never deprecate anything and Apple’s “kill anything not new” would be nice :P[/quote]
Indeed.