Archive for the ‘Development’ Category

Goodbye Mac App Store

Thursday, March 2nd, 2017

While Jettison and HistoryHound are still supported and sold on the St. Clair Software website, I’ve pulled them from the Mac App Store. The versions that were in the Mac App Store were older revisions, and it just didn’t make business sense to rearchitect the apps to meet Apple’s current requirements for approval so they could be kept up-to-date.

For both applications, complying with Apple’s sandboxing and feature constraints to get them approved for sale would have required significant rewrites. And in Jettison’s case, it would also require that buyers download a separate helper app to enable its full functionality. I realize that some people will be put off or inconvenienced by the fact that these apps are no longer in the Mac App Store – my apologies if you’re one of those folks, but it just doesn’t make sense for Jettison and HistoryHound.

Without going into a full-on rant about the Mac App Store (I could ramble on for days), let’s just say that while the Mac App Store is convenient for consumers, it doesn’t really serve the needs of some developers. Much has been written about it already (here, here, herehere and here, for example) so I won’t rehash it all – and despite years of “constructive criticism” from developers, Apple hasn’t fixed some major problems.

I hope you’ll continue to purchase our applications, as well as those from other independent developers selling outside the Mac App Store. While it’s a little less convenient than the Mac App Store, it allows us to bring you the best software we can, and also gives us the opportunity to foster a two-way relationship with you – both of which really matter to us.

– Jon

App Tamer and CPU-hog detection

Friday, December 30th, 2016

So I’ve noticed in Sierra that some of its “helper processes” (apps that run in the background to do various tasks) will occasionally start using 100% CPU for no reason. In particular, I’ve seen the com.apple.appkit.xpc.openAndSavePanelService process stay pegged after a file dialog is done – it just sits there and consumes CPU while doing nothing. Quitting the app that was showing the file dialog will stop the CPU-hogging, but it otherwise continues indefinitely.

I’ve been wondering if this might actually be the source of the much-talked about Consumer Reports findings that the new MacBook Pros have very inconsistent battery life. Their results varied widely from test to test (on the same computer) – maybe one of the WebKit helper processes was just flipping out once in a while due to some underlying bug in Sierra’s interprocess communication or process management services.

While that’s just my own random speculation, the issue of processes running amok seems to be a recurring annoyance to some folks. To help you detect this sort of stuff, I’m adding an option in App Tamer to notify you if a process starts consuming excessive CPU time. If it does, it gives you the options shown in the screenshot.

 Can’t hurt, right? Shoot me an email (AppTamer at stclairsoft dot com) if you’re interested in trying it out and doing a little testing for me.
 – Jon

Developer Tip: Avoiding the Discrete GPU

Friday, December 16th, 2016

So I’ve run into this issue both as a user and as a developer – on MacBook Pros that have both a discrete and integrated GPU, fancy animations will cause the system to switch to the more powerful discrete GPU, reducing battery life. Chris Liscio wrote a great post explaining what’s going on and what to do about it (from a developer’s perspective). The key takeaway for most developers:

This whole problem can be very easy to solve. You just have to set NSSupportsAutomaticGraphicsSwitching key to YES in your application’s Info.plist. The trouble is that an OpenGL context is being created, which defaults to switching the dGPU on. Enabling this flag in the plist will very likely fix the problem on its own, as the frameworks should Do the Right Thing (more details below) if they need access to OpenGL.

Go read his whole post for all the details.

 

Sal Soghoian’s position eliminated at Apple

Thursday, November 17th, 2016

Wait. Who? Sal Soghoian is Product Manager of Automation Technologies at Apple. That basically means he has been the motivating force behind AppleScript, Automator, application scriptability and the technologies that underly them. He’s been doing it for the last 20 years, and I don’t think most Mac users understand how important his influence has been to the platform we use and love. He’ll be leaving Apple on December 1, as his position has been “eliminated for business reasons.”

While I’ve met Sal several times, I don’t know him on a personal level. I’ve seen him speak numerous times, and like many long-time Mac developers, have benefited from his passion and consistent evangelism of system-level scriptability.

Why do I care? Indeed – why do we care about this? Well, let’s rewind a bit and set some groundwork for why Sal’s contributions matter so much.

Interoperability – from Copy/Paste to AppleScript. We all take copy and paste for granted – of course I can copy an image out of Photoshop and paste it into Mail, right? Well, it didn’t always work so easily – the Mac was the first major platform that standardized that by providing system-level support for standard image types and an extensible way to move them between applications. The key was that it was natively supported by the system, so developers could add it to their apps and it worked the same way, with the same basic data formats, in all applications. You could copy and paste between any applications.

Like copy and paste, in 1993 Apple added system-level support for scripting. Instead of every developer inventing their own, custom scripting language that only worked in their application, Apple created AppleScript – and more crucially, AppleEvents beneath it that provided a rich way to send commands and data from one application to another. Many applications have scripting dictionaries built into them, letting you, or any application, send commands to do useful stuff.

Anyone can create simple or hugely complicated AppleScripts to do all sorts of things – from changing the format of all image files in a folder to automating email handling to batch-processing audio and video clips for movies. You can use all the best-of-breed tools on the Mac and string them into workflows that meet your specific needs. That’s always been one of the Mac’s big advantages – you can combine applications to accomplish more than any of the individual apps can do themselves. Apple’s Automator application even tried to make this accessible to everyone – with varying levels of success, depending on who you talk to.

But I don’t use AppleScript. So I don’t care, right? You may not directly use AppleScript, but many applications use AppleScript or AppleEvents in lots of little ways. iTunes, for example, lets you pause, play, go forward and backward a track, change playlists, add properties to songs, and a zillion other things. Those little iTunes controller apps that live in your menubar or dock? They use AppleScript to talk to iTunes. The ones that add lyrics to the currently playing song at the push of a button? Yup, AppleScript. Applications that grab the current page from your browser? AppleScript. The “contact us” button in an app that automatically creates an email in Mail with a subject and the To: address filled in? AppleScript. There’s probably something on your Mac that uses AppleScript or AppleEvents, even though you’re not aware of it.

So where does Sal come in? Sal is the guy at Apple who has kept this whole vision alive. He prodded developers to add AppleScript capabilities to their applications. He kept system-level scripting a priority – or at least on the radar – at Apple. He spoke at WWDC and numerous other conferences, showing how powerful the technology was. He explained to developers how a little work on their end could yield huge benefits for scripting-aware users.

My fear is that with Sal’s departure, Apple’s waning interest in scripting, and application interoperability in general, will be gone for good.

Losing interoperability. So if system-level scriptability disappears, what do we lose? For starters, it makes it harder for one application to talk to another or to use another application’s capabilities. Those iTunes controllers wouldn’t be able to talk to iTunes. My own product, Default Folder X, tracks your recently-used folders and then lets you go back to one of them in the Finder, Path Finder or Terminal. The latter two wouldn’t be possible (or would be much harder) without AppleScript. And when someone tweeted me that they wanted to use iTerm2 instead of Terminal, I could add that in 10 minutes because iTerm2 supports AppleScript.

Yes, those are little things, but sometimes they’re the little things that separate an acceptable application from an awesome one. I’ve always felt that the interoperability between Mac applications was one of the things that distinguished the Mac from other platforms like Windows. Even when you can get the same applications on both OS’s, everything is just tied together better on the Mac. I hope that doesn’t change.

Oh, and if you do use AppleScript? Yeah, this sucks even more.

Dash gone from the App Store – what the heck, Apple?

Thursday, October 6th, 2016

Just a random PSA for developers: This just happened:

https://blog.kapeli.com/apple-removed-dash-from-the-app-store#what-happened

Summary: Bogdan Popescu, the developer of Dash (one of the most awesome programmer’s reference tools ever), contacted Apple to convert his personal developer account into a company account. Apple started the process, then disabled his personal account and revoked his permission to sell apps on the App Store. It looks like another capricious and supremely unhelpful App Store move from Apple. Thanks guys – you make it so much fun to develop for your platforms.

Default Folder X 5.0.6b5 fixes some glitches with Sierra betas

Wednesday, August 17th, 2016

There’s a new public beta of Default Folder X that addresses issues with the latest beta releases of macOS 10.12 Sierra. I’m also testing some changes to Default Folder X’s activation method that get rid of problems with it occasionally not loading in some applications, as well as fixing a hang that could occur under some circumstances. Oh, and there’s also improved support for LaunchBar.

You can see the full change history and download a copy from the Default Folder X Testing page.

If you’re running App Tamer, make sure you get a copy of the latest App Tamer Beta too.

Default Folder X 5.0.6b1 brings support for macOS 10.12 Sierra

Wednesday, June 22nd, 2016

SierraA new public beta of Default Folder X 5.0.6 is available, adding support for the developer release of macOS 10.12 Sierra that was unveiled at WWDC last week. It also adds “always sort by name” to your Favorite Folders list and fixes a couple of compatibility issues.

More details and download links are on the Default Folder X beta testing page.

Integrating Default Folder X with LaunchBar

Thursday, March 10th, 2016

launchbar_320@2xI’ve long been an avid (addicted) user of LaunchBar – if you’re a person that’s keyboard-based like I am, it’ll save you ridiculous amounts of time. Hit Command-Space to activate LaunchBar and then start typing – you can do anything you want to without taking your hands off the keyboard.

Now I’m happy to announce that Manfred Linzner, an engineer at Objective Development (the makers of LaunchBar), has put together a LaunchBar action that gives you access to Default Folder X’s favorite and recent items within LaunchBar.

If you’re a LaunchBar user, you just need to download the Default Folder X Files action from Manfred’s Github repo. After it downloads, double-click on the .lbaction file and LaunchBar will offer to install it for you. Then it’s just a matter of invoking LaunchBar and typing the first few letters of “Default Folder X Files” (or “DFX”) to get this:

launchbar_dfx

Hit the right arrow key from there to select any favorite or recent folder or file from Default Folder X, or Command-right-arrow to narrow the search to just your Favorites, Recent Files, or Recent folders.

launchbar_dfx_select

Yet another way to get to your files and folders faster – thanks Manfred!

Auto-Update Vulnerability in Sparkle

Wednesday, February 10th, 2016

A security vulnerability has been found in Sparkle, the framework used by many Mac applications to check for and download software updates automatically. Full details are at:

http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/

While some of our applications (like HistoryHound) are using older versions of the Sparkle framework at the moment, they all use encrypted HTTPS connections to check for and download updates, so there’s no chance of a man-in-the-middle attack, as described in the report.

So you can safely leave automatic update checking turned on in all of our products – it’s being done safely.

– Jon

Finally! Default Folder X 5.0 Released!

Monday, January 11th, 2016

 

Default Folder X 5.0 is finally done and out! You can get it from https://www.stclairsoft.com/DefaultFolderX/index.html now. A quick list of the new features is at https://www.stclairsoft.com/DefaultFolderX/release.html, though there’s so much new and improved that it’s impossible to really list it all. It’s a ground-up rewrite that brings in all the improvements I’ve wanted to do for years.

Important details, for those of you who haven’t been following the betas:

  • It’s fully compatible with El Capitan and doesn’t require that you turn System Integrity Protection off anymore.
  • Yes, it’s a paid upgrade. It’s $14.95 unless you bought your license on or after June 1, 2015.
  • There are more features that are on the way – I held back a few in order to get 5.0 out sooner.
  • Localization in other languages still needs to be done – that’s a high priority now.
  • Version 5 also runs on Yosemite, but not on earlier versions of OS X.
  • If you turned off System Integrity Protection to use version 4 on El Capitan, you can turn it back on now.