I had assumed that all builds now on Mac are for 64 bit Intel but see that I can still choose either 32 or 64 bit.
The issue I am having is that an old plugin I use (that is no longer updated) won’t compile for 64 bit Cocoa but will for 32 bit Cocoa.
Can someone please explain the difference for building for 32 or 64 so I can work out whether I must replace the plugin with another solution or whether it will make no difference to the end user if I build a 32 bit app.
Thanks.
64bit will only matter for a small number of apps that need a lot of memory. 32bit apps can do a maximum of 3.5 GB of memory. 64bit can have a lot more.
Users only know that 64bit is better than 32bit and expect that you do a 64bit version eventually. And yes, you will have to replace the plugin at some point in time. If your plugin is the Einhugur DataGrid or StyleGrid: this was a lot of work to replace for me, too. Thomas Tempelmann has worked with Christian Schmitz to make the Cocoa listbox available for Xojo.
if you build for the Mac App Store, then the 64 bits is required by Apple…
@Jean-Yves Pochez : not yet. For iOS you are correct.
[quote=322675:@Beatrix Willius]64bit will only matter for a small number of apps that need a lot of memory. 32bit apps can do a maximum of 3.5 GB of memory. 64bit can have a lot more.
Users only know that 64bit is better than 32bit and expect that you do a 64bit version eventually. And yes, you will have to replace the plugin at some point in time. If your plugin is the Einhugur DataGrid or StyleGrid: this was a lot of work to replace for me, too. Thomas Tempelmann has worked with Christian Schmitz to make the Cocoa listbox available for Xojo.[/quote]
Thanks, Beatrix. That makes it clearer for me. I will build the 32bit version and check it works on Sierra on my newer Retina iMac to be absolutely sure.
I know I will have to update or replace it at some point because I hope to do an iOS version and a version for the MAS but right now it would be too much work for the amount of time I have available.
Right now, for most things; there’s not much difference, 64-Bit apps can be faster and can utilize much more memory.
However after much tooing and frooing with an Apple engineer, he informed that only 64-Bit Cocoa is considered current and everything else should be consider deprecated. I’ve encountered some major issues in Apple’s graphics toolbox on 32-Bit, that pretty much won’t get fixed. Building 64-Bit was the only way (and I’m thankful to Xojo for offering 64-Bit).
Not quite yet on the Mac App Store, but it won’t be long before it happens.
TL;DR: You should migrate to 64-Bit, the sooner you do it the better.
p.s. Migrating to 64-Bit doesn’t mean that you won’t encounter any Apple bugs, it just means that they are more likely to fix 'em. Some PDF functions were broken in the Sierra beta’s and should finally be fixed in the next release (8 months later).
I would suggest that you take advantage of Xojo’s power and also ship a Windows version, and when it becomes available an Android version. If can cover more bases, you increase your chances of more success and survival. After all, you’re using the best x-plat development tool there is.
+1
Not forgetting that there are a bunch of customers who think 64bit is better and will for sure diss (read: write bad reviews) when your app is still 32bit.
Thanks, Sam (and Christoph). That’s good advice. I do actually have a Windows version and have just started working on the Mac version now and hence ran into this 32/64 bit build issue with the ElfData plugin (really old) that I use for all my fast string processing for things like huge string appends, mid functions, byte functions, UTF8 character codes and Multi-search-replace.
I know that potentially MBS plugins could help as a replacement but we are talking a lot of work from the ground up (across my entire project and practically every function in it) to do this even if MBS or other plugins can help me. I may just get the app out as is and build for 32 bit and then right away start work on replacing ElfData somehow and if I succeed release a 64 bit update etc.
64 bit computing DOES give you access to a huge amount of memory and thats the primary benefit
But 64 bit may not be any faster - in fact it can be slower
Data fetches as 2x as wide, instruction fetches are 2x as wide, etc and shoving around all those extra bits takes a toll
And not all graphics issues are better in 64 bit
[quote]I’ve encountered some major issues in Apple’s graphics toolbox on 32-Bit, that pretty much won’t get fixed. Building 64-Bit was the only way (and I’m thankful to Xojo for offering 64-Bit).
[/quote]
Flood fill doesnt work in 64bit builds.
Until 64-bit support is out of beta, I would recommending testing your app out as 64-bit but continuing to ship 32-bit builds to customers.
I was asked by Apple to update one of my older Apps to 64 bit. However, my CertTools while fine for 32 bit was no good for 64 bit so I submitted without MAS verification and it was accepted on the MAS. I would like to validate receipts but I am struggling to incorporate the code from the free Receipt tester app( from Ohanaware/Sam Rowlands) into my App. But I am having problems. Has anyone done this successfully?
or is there a better solution ( excluding App wrapper etc as I like to code sign my own apps)
I appear to have solved my problem. In the Open event of my App I deleted the code
const const hardCodedBundleIdentifier = “com.ohanaware.svgutilities” = “com.ohanaware.svgutilities”
and ensured that my hardCodedBundleIdentifier was in quotation marks and the all worked ok! Will submit this version to MAS.
[quote=393460:@Jonathan Malthouse]I appear to have solved my problem. In the Open event of my App I deleted the code
const const hardCodedBundleIdentifier = “com.ohanaware.svgutilities” = “com.ohanaware.svgutilities”
and ensured that my hardCodedBundleIdentifier was in quotation marks and the all worked ok! Will submit this version to MAS.[/quote]
Are you Sam? Those bundle ids are Sams Ohanaware.
Yes I know Sam Rowlands wrote the code and Ohanaware distribute it.
My app is now on the MAS.
[quote=393712:@Jonathan Malthouse]Yes I know Sam Rowlands wrote the code and Ohanaware distribute it.
My app is now on the MAS.[/quote]
“I am Batman Ohanaware”
[quote=393712:@Jonathan Malthouse]Yes I know Sam Rowlands wrote the code and Ohanaware distribute it.
My app is now on the MAS.[/quote]
What he was referring to was the
You should use your own bundle Identifier there instead of Sams.