BKeeney Software Inc. is proud to announce that ARGen, our ActiveRecord Generator utility for Xojo developers, has a new major update. Version 3.0 includes a host of new features including the ability to generate ActiveRecord classes for Xojo iOS projects, the ability to use GUID primary keys, the option to include a database update module, include an audit trail module, and include a UI localization module. There are also new ways to arrange your user interface layouts that can save you even more time when initially creating a project. In addition to these major new features, ARGen fixes a number of bugs and provides more enhancements.
ARGen has versions for macOS and Windows. It costs $99.95 but can be used in limited mode at no cost. Existing version 2.x users will be provided an upgrade opportunity with a 50% discount or they contact us at support at bkeeney dot com to get an upgrade coupon.
Pricing, examples, and more details can be found at the project homepage at https://www.bkeeney.com/allproducts/argen/
3.0 Release Notes:
* iOS ActiveRecord!
* Reorder fields in the order they should be displayed. This would work both on List and Edit forms.
* Name labels for generated UI elements
* Switch between horizontal and vertical alignment for UI fields and labels
* Projects can now have individual Namespaces
* GUID support (except for ODBC connections)
* Can now include a Database Update module
* Can now include an Audit Trail module
* Can now include a Localization module
* Warnings for aggregates that conflict with Xojo (note below)
* New database connection window
* New app icon
* Oracle databases are no longer supported
* Add / Edit dialog now shows in web version (#3556)
* Icon now displays properly in alerts (#3474)
* PostgreSQL Views now working
* Control init on add and edit windows
* Preferences now correctly handles prefix and suffix settings
* Selecting suffix no longer causes a compile error
* Confirmation dialogs are now set up properly (#3643)
* MenuBarVisible is no longer false on any template windows (#3475)
* Rescan Schema works again
* Database specific PreparedStatements
* Instances of MsgBox replaced with MessageBox (#3474)
* Enhanced Save() on add and edit windows
* Listbox.Open() now has a ColumnWidths placeholder for convinience
* Desktop projects now created with HiDPI on
* Desktop projects now default to 64 bit for Mac
* Opening a SQLite project automatically attempts to connect (#3596)
* Auto-Generate UI step is now easier to understand
When using aggregate like Count(), Max(), Min() some DBs will return the aggregate as the field name.
Added code to warn on open project that there is invalid for xojo field names, and fail generate.
We’ve recently had a number of projects that required the use of a serial devices in desktop applications. In all cases the clients said the devices are, “easy to use,” since they act just like a keyboard. If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.
Several projects required the use of barcode scanner. Having a barcode scanner work as a keyboard makes sense, I guess. It means that it can work with literally any application, anywhere, any time. All it needs is focus on a text field and whatever the scanner sees it puts into the control.
In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information. Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.
If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it. Putting the focus in a field and waiting for information is easy. It’s not so easy when that information could come at any time. Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.
If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer. It means that when your barcode/sensor field loses focus you have to get it back (or you lose information). Do you do this right away or wait a few seconds? And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField? It can be a nightmare to try and figure out and get right. The differences between Mac and Windows and Linux can be frustrating!
The answer that we ended up implementing was putting the barcode readers into serial mode. I’ve not run into a barcode scanner yet that couldn’t be used in serial mode. Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer. On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem. If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.
Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField. The class then distributes the data to the objects that can consume the data. What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects. Each of the objects has an Interface with a simple HandleBarcode method. This is known as the Observer Pattern and there’s an example that ships with Xojo.
My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode. However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away. I’m not sure what we would have done if it had been a Mac or Linux project.
Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list). Having to deal with devices that act as keyboards not so much. I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.
What’s been your experience with serial devices in Xojo?
I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!
First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.
Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.
To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).
The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.
Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?
Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.
Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.
Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.
The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.
Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!
So what are your thoughts on R2.1 and the Short-term Roadmap?
Have I told you how much I love the Xojo community? I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more. I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product. It’s a big deal. Really!
If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey. Programming is hard. Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard. Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.
Even Xojo pros, such as myself, have need of help. Xojo covers Mac, Windows, Linux desktop, console, and web apps. It does iOS apps for iPhone and iPad. It now does Raspberry Pi for heavens sake! It works with dozens of different databases. There is simply no way any one person is going to know everything there is to know about Xojo. It just can’t happen. So yes, I go to the forums, all the time, and ask for help.
Just the other day I asked for some help with WooCommerce. Not Xojo related, really, but certainly related to a project we’re working on for a client. Within a few hours I had half a dozen developers private message me saying they might be able to help. Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.
I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years. I think I’d be hard pressed to find such a friendly community. I call many on the forums my friends even though I’ve never physically met them. The few that I’ve met in person have lived up to their forum reputations and are really friends for life.
So maybe this is my belated Thanksgiving post. I am thankful that so many years ago I jumped both feet first into the tool. I asked questions – many of the silly and redundant. I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.
So if you are in need of a cross-platform development tool I highly recommend Xojo. It ain’t perfect but no development tool is. If you jump in I think you’ll love the community. I know I do.
What say you fellow Xojo developers?
The folks a Ohanaware wrote a blog post a few days ago that all Xojo developers creating Mac apps should read since it involves the UTI (Uniform Type Identifiers) created for your Xojo applications for Mac OS X.
The basic summary is that there is a bug in the 2015 R2.x series (possibly older versions are affected too) that can mistakenly lump all of the UTI’s into the Exportable Types that goes into the application’s plist file. This error can cause the Launch Services database to get corrupted and in Ohanaware’s case, prevented Quicklook from previewing PDF’s.
Thankfully, there are some simple things you can do to prevent this from happening. The first and best solution is to open the FileTypes Editor in Xojo and make sure its settings are correct. Under Build Settings in the Navigator choose OS X. Then press the File Types button that’s in the Inspector. This opens the Editor. The checkboxes on the left should ONLY be checked if your app is creating the file otherwise those files will get lumped into the Exportable Types.
At this point I’ll take a step back and let you know that I’ve never even really thought about this editor – ever. The user interface is very simple but it lacks information on what these things do. The heading on the dialog does say “Select which file types your application will accept as file drops under OS X” which is pretty clear. However, as Ohanaaware found out it’s exporting it incorrectly.
I did a quick search in the Xojo User Guide and there is a brief blurb describing the roles in UserGuide-Fundamentals PDF. Otherwise, I’ve been unable to find any documentation on the exact use of this dialog.
The second method of fixing this problem is to use App Wrapper utility. This Ohanaware utility has been around for a few years and is a great way to code sign your applications as well as get all those little nasty bits set in your application for release. Have a Retina capable application? It can verify that the assets are all there. Releasing for the Mac App Store? It can help you set the entitlements and also strip your project of verboten items that will cause automatic rejection. And now, after their experience, version 3.4.1 of App Wrapper will do check these settings and can move them from the Exportable Types list to the Importable Types (which is what they should be doing).
Because this was such a disastrous problem Ohanaware also released a free utility called “Preview Reset” for Shine customers that were bit by this bug. I’ll give Ohanaware credit for owning up to it and working diligently to find the solution.
Ohanaware reported this bug to Xojo: <feedback://showreport?report_id=40907>. The good news is that it’s marked as fixed and should be in Xojo 2015 Release 3. However, it’s still in beta so until it’s released take extra special care with your Mac builds.
It’s been a very busy first half of the year at BKeeney Software. We’ve just finished up three medium sized web apps. One was deployed to Windows Server, one deployed to a Linux web server, and the last to Xojo Cloud. We’ve done a couple of small web apps to a Xojo friendly host too. I will describe our experiences below.
The first project was a CRM project where we converted a really old MS Access and ACT! system to Xojo. The UI wasn’t all that complicated but the data conversion was a pain since it was so dirty. We ended up using a MySQL database server.
Since we didn’t want to go through the hassle of getting an IIS server we made the decision to deploy as a standalone app. The hardest part of the whole installation was figuring out how to create the service. We ended up using NSSM – the Non-Sucking Service Manager http://www.nssm.cc to create the service. After that, installation and updates were a breeze by simply stopping the service, changing the files, and restarting the service. We are able to VPN into the server and copy the necessary files over.
The server was virtual and running on a VMWare server. Despite our specifications the server was set up initially with a single core (virtual) processor. Performance all the way around sucked. We complained, the client complained, and as soon as they upped it to dual core processors (as we specified) everything went smoothly after that.
The second project was another CRM-type project though a little smaller. It was using an SQLite database. We converted the data from a FileMaker database. The data was much cleaner and more straightforward so it was a relatively easy transition.
The client decided to host on Xojo Cloud so deployment is done from with the Xojo IDE. The only file we didn’t deploy via the IDE was the database itself which we transferred via SFTP to the appropriate shared document directory on the Xojo Cloud server.
Xojo Cloud, for the most part, works flawlessly. There have been occasions, however, where it fails to upload properly. It’s a frustrating experience, to be sure, but Xojo customer service has always been able to fix it. When it happens on a weekend you’re kind of out of luck. Here are a couple of suggestions to try and get around the issue: 1) Restart your server via the Xojo control panel. 2) Change the application ID of your application and try uploading again.
Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table. It still worked but some of the queries were taking *minutes* to complete. The decision to move over to MySQL wasn’t a hard one.
You’d think that updating an existing app would be easy. This one turned out to be anything but easy. Since this one bites a lot of people deploying Xojo web apps to various Linux distorts it’s worth writing them all down.
- Until Xojo web apps are 64 bit you’ll have to make sure the 32 bit compatibility libraries are installed. Each is different so it’s ‘fun’ finding them. Honestly, check on the Xojo forums to see what people have found. Hopefully, this becomes a non-issue with Xojo 2015 R3 being scheduled to compile 64 bit apps.
- Make sure permissions are 775 for all files and directories *including* the overall directory. The latter one has bitten me more than once.
- Make sure permissions for the config.cfg file is 664 or 666 (I’ve seen it both ways and I’ve never had a problem with either one).
- Make sure the owner and group of the files matches that of the system. If you’re FTP client shows owners/groups and it says something like “mixed” you’ve got a problem. You’ll need to figure out how to change the owner/group on your own. This may involved getting SSH access. It may be easier to work through the CPanel File Manager to upload files because you’re guaranteed, then, to have the right owner/group.
- Make sure the .htaccess file has been uploaded. Since it’s a hidden file on Mac OS X it’s easy to miss this one. If you zip the output directory and then upload the zip it will be there automatically. If you’re zipping the contents of the directory don’t forget it!
- Does the server have libicu installed? Xojo 2015 R2 requires libicu and if you don’t have it your app will just crash with maybe an obscure error in the error log like “Can’t find missing file.” I had this happen to me this week and when I reverted to 2014 R2 the app started up right away. If you suspect you’re missing a library and have SSH access, try starting the app via the command line. It will tell you what the missing library is. You don’t always have SSH access so that’s kind of a drag.
Not really an issue with web app deployment, per se, but it’s an issue we deal with quite a bit. MySQL on Mac OS X doesn’t care what the case is of a table or view. tTable (mixed case) is the same as ttable (all lowercase). On Linux and Windows this does not appear to be the case. I know there’s a system variable that can turn this on or off but for this project the client had existing databases on the server and I really didn’t want to muck anything up on them. Many queries that were running great on our local (Mac) system were not on the server. Switching everything to lowercase isn’t a big deal (especially with ActiveRecord) but some db apps this will be a nightmare. So don’t forget to test!
1701 Software Inc. http://www.1701software.com
We have deployed to 1701 Software several times in the past six months for ourselves and for various clients. We’ve found their servers to be Xojo friendly from the get go (not so with most hosts) and their service is excellent. They also offer a number of database options that Xojo Cloud does not like CubeSQL and Valentina in addition to MySQL and PostgreSQL. Frankly, the fact that they are Xojo developers too makes them the top of my list of non Xojo hosting services. Their prices are pretty good too for those that are price conscious.
That is our experience with deploying Xojo web apps in the past six months. When everything works right it’s incredibly easy. When it doesn’t – well, you tend to swear like a sailor. Hopefully you’ll find this guide to be somewhat useful. Anything I forgot?
[Edit: Updated to not include an implied timeframe for the R3 release.]
The question comes up every now and then on what’s the best target to develop for: desktop or web. The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.” You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding. Let’s go over some of those issues. Let’s start with desktop apps.
Xojo has been making desktop apps for it’s entire history. Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available. You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.
With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines. These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.
The major downside to desktop apps is deployment. Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version. Example: You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing. All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version. For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software. A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well. So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting. From experience it’s a pain to deal with.
Desktop apps that are part of an n-tier system also need to be programmed differently. You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time). You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic. The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server. The middleware app does all of the business logic and handles the transactions between the database and the client apps. It’s a fair bit of work and is not what I would consider a simple undertaking. But at least you generally only have to update the middleware app most of the time and the clients can stay the same.
Web apps, on the other hand, have several advantages over desktop apps. First, they are n-tier by design. Each client has its own set of logic via Xojo WebSessions even though there is only one application running. The user runs in a browser and everything is processed on the server. So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running. Having only one instance to update is really nice (and quick). Web apps eliminate many deployment challenges.
Web apps aren’t perfect though. Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it. All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.
Web apps run in a browser. That’s both good and bad. Users can access your app as long as they have internet access. In some areas this is no big deal and for others it’s a huge deal. Browsers also have a lot of built-in security to keep bad things from happening on your computer. This security also limits what your browser can do in terms of file handling local. Xojo does not currently support drag and drop operations with the browser.
Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger. That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps. Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs. Web Containers go a long way towards solving this issue but it’s not ideal.
Not all web browsers are created equal. Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous. This means there are a lot of different browsers, and versions of those browsers, being used by the general public. Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then. Mobile browsers have their own set of issues that you might need to take into account as well.
Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do. For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app. 1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see. To get around this most websites do data paging where they only show you 25 to 50 records at time. Again, not hard to do but one more thing to develop. Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.
Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling. Your app will react differently when accessed by 1000 simultaneous users than when it has 10. The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers. Finding a good web server to host your web app can be challenging too. Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.
As you can see, there’s is no right answer. Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses. Before you start development work you need to think through the implications of doing each.
Happy coding! Was there anything I forgot to mention in the debate of desktop vs web apps?
The Spell Checker plugin has two different spell checking modes. In the first mode it works with the native spelling dictionaries on each platform. On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries. If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries. There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.
There is no Linux version at this point due to lack of interest.
More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/
Xojo makes developing Mac OS X apps very easy but getting those apps ready for distribution can be a daunting task. Apple has had the option for a while to not open applications from unknown developers using a security option that Apple calls Gatekeeper. Gatekeeper, in effect, restricts which apps a user can run on their computer. This theoretically helps protect users from installing malicious applications.
Gatekeeper has 3 settings: Mac App Store that allows only applications downloaded form the Mac App Store. Mac App Store and Identified Developers that allows Mac App Store and applications signed by certified Apple developers. Anywhere that allows any application to be launched. The default in Yosemite, is the 2nd option (Mac App Store and identified developers). Since Apple only recognizes its own developer certificates they have more control over the entire process.
To pass Gatekeeper you need to have a verified Apple Developer Account. Then use Keychain Assistant to request a certificate from Apple through the Apple Developer portal. Setting up this account costs $99 a year and it isn’t too difficult – Apple has some nice instructions for the novice developer to figure this out. However, signing your Xojo app isn’t the most straightforward thing to do, but we’ll get to that in a minute.
If you are trying to distribute your app on the Mac App Store you have to worry about a myriad of things that Xojo doesn’t automatically give you. The first is code signing your application. Other issues include Retina display settings and Retina image sizes, how you interact with the system via the App Sandbox, and if you are using iCloud or other Apple online services, Push Notifications or Game Center.
That’s a ton of stuff to figure out how to add on your own to your project. For several years we had our own postscript build that called a bunch of command line utilities that did the code signing, set the proper plist entries and so on. It was a pain to maintain and move to different projects for a variety of reasons – one of them being that finding out the cause of a script error wasn’t always straightforward!
Enter App Wrapper from Ohanaaware. We’ve used App Wrapper 2 for a while and have been extremely happy with it. It takes the guess work out of configuring your Mac OS X distribution because the utility remembers the settings you’ve used for each application. This includes remembering which code signatures to use. Since we create apps for ourselves and for clients this is particularly useful.
App Wrapper 3 has five panels to choose from. The Report tab gives an overview of everything in the application along with reasons why it may be rejected from the Mac App Store. In the example below I’m showing ARGen, our ActiveRecord utility, that is NOT in the Mac App Store. If I did try to submit to the Mac App Store it would be rejected for three reasons: first, it uses the Sparkle framework, and the eSellerate libraries – both of which are rejected by Apple and are unnecessary in Mac App Store applications. The second reasons is that CubeSQL references QuickTime in the plugin (which is surprising since it’s a database plugin).
The General tab lets you set a number of variables needed by Apple. What’s the Category, minimum Mac OS X that can run the application. The copyright information. The version information, high resolution mode (Retina), which code signature to use, registering an Apple help file, and how the app should be packaged for you (to name the highlights). This is, by far, the panel you’ll need to pay close attention to.
One thing that was less than clear to me when setting up my app in App Wrapper 3 was the About Info credits. In version 2 there was checkbox to include this in the build. In version 3 it gets put into your application. The solution is to simply clear the text field but it’s not obvious. The default text is using my name and information. If I’m creating client builds I will now have to deliberately clear this out before I send to the client. Otherwise, there will be a Credits.rtf file in the Resources directory of the bundle.
For the Mac App Store the code signing certificate will automatically set the Packing for you. For non Mac App Store distribution you have the option of no packing, zip file, or Apple Installer. For us, we distribute via disk image (DMG) so we leave it to none.
The Capabilities panel is all about the App Sandbox and how the app interacts with it. There are a number of things with Sand Boxing that will make your development life a joy. All that fun stuff is beyond the scope of this review but if you’re going to submit to the Mac App Store you should really do some research!
The Info panel is all about setting up the info.plist properly for your app. The top list is what changes App Wrapper will add to the plist and the other sections are for Document Types, URL Aliases, and Uniform Type Identifiers. Some of these are set from Xojo and others are not.
The Other panel lets you clean up the application bundle. You can remove subversion remnants, DS_Store files, language files, and whether or not to clean up some of the architecture such as removing any old PowerPC code, or restricting it to Intel 32 bit or 64 bit. You even have the ability to fine tune the files and ignore them, delete them, delete them for the Mac App Store and so on.
To actually wrap your application you have two options. The first is to do it all manually. Drag your built executable on to App Wrapper 3, set it up all up, and simply hit the Wrap button in the upper right corner. You’ll want to do this manually a time or two to make sure there are no major errors.
The second, and probably preferable way, in my opinion, is to hit the Xojo Script button and drag the script file into the Finder and then into your project and put it under the build steps for Mac OS X (supposedly you can go direct from the App Wrapper to the Xojo IDE but I couldn’t get this work). Then it’s just a matter of hitting build in the Xojo IDE. The application is built and the script will use the executable and run App Wrapper in the background. Voila! You have a code signed application that’s ready for upload to it’s final destination (assuming no errors).
In App Wrapper 2 we used the command line option with our own Postbuild script. Version 3 doesn’t appear to allow this so we’ll have to modify our workflow a bit to use it but it doesn’t appear very onerous of a task (at this point). The benefits of using App Wrapper far outweigh the chore of setting it up.
Once your application is wrapped there are a couple of options for testing. The first is to test the application with Quarantine or RB App Checker Lite. Quarantine lets you start an application as if it was downloaded from the internet. This is handy because applications built on your machine are automatically considered ‘safe’. RB App Checker Lite from Rainer Brockerhoff http://brockerhoff.net/RB/index.html lets you verify the certificate and check the entitlement settings before submitting it to the Mac App Store. Both of these tests are useful.
App Wrapper 3 has three purchase options. First is the 30-day Single User “Pay As You Go” option for $9.99 that runs for 30 days but can no longer be used at the end of the 30 days. The 1-Year Single User plan costs $20. The 1-Year Small Team plan costs $199.99 and lets App Wrapper be used by up to 10 developers. Both the Single User and Small Team options have free upgrades for a year after purchase and allow you to use the application even after the time period is up (no usage expiration).
The Pay As You Go option seems very odd. For a mere $20 you can get the Single User plan and can use it forever. I see no advantage in the Pay As You Go option and, to me, is more of a software rental plan.
[Update:] The 1-Year Single User plan is normally $49.99 but is $29.99 until the end of November. Sorry for the error.
If you haven’t already checked out App Wrapper I recommend that you do. It is by far the easiest way to get your app ready for Gatekeeper and the Mac App Store. Without it, you may spend a lot of time figuring it out on your own. From experience I can say that Apple’s documentation assumes you’re using xCode so figuring it out for Xojo makes it that much harder. Ohanaware has already done it for you!
For more information on App Wrapper 3 please visit http://www.ohanaware.com/appwrapper/.