Archive for the ‘Random Ramblings’ Category
Wednesday, June 27th, 2018
I’m not a huge podcast junkie – my listening tends to ebb and flow as demands on my time change. However, Mac Geek Gab is one that always entertains, has great tips and information for getting the most out of your Mac, and helps with the weird little issues that inevitably crop up. Of course, it doesn’t hurt that they’re big fans of St. Clair Software’s products, too – it’s nice to hear my name in lights every once in a while 🙂
So, as I was reminded by Dave’s mention of Jettison in their 13th Anniversary episode a couple of weeks ago, I’ve been tuning in for years now and think some of St. Clair Software’s customers might really enjoy and benefit from the podcast. So there you are – go give them a listen, support their sponsors, and learn some new tips and tricks!
Saturday, September 9th, 2017
Michael Tsai and Jason Snell brought it to my attention that Default Folder is almost 30 years old. I guess that makes me a stubborn old man at this point…
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, here, here 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.
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.
Thursday, October 6th, 2016
Just a random PSA for developers: This just 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.
Thursday, January 21st, 2016
I probably shouldn’t be writing this – I’ve certainly got better things to do with my time – but heck, this really gets to me. I’ve gotten several emails over the past week that are similar to this one:
I am fairly sure you sneakily intended to try to get me to have to BUY a new key for DF 5. Please note I used the word SNEAKILY.
Sorry, it won’t work, I won’t be using it. Maybe that is what you intended…
His email was in response to a mailing announcing Default Folder X 5, which said:
… And because you purchased an earlier version, you can upgrade to Default Folder X 5 for only $14.95 USD.
and gave the recipient a link to a web page that says:
If you bought a license before June 1, 2015, there is a $14.95 upgrade fee for version 5.
and which has a download button that shows you a page that says:
Before you install version 5, we’d like to make sure you know that you’ll be asked to pay a $14.95 upgrade fee if you purchased Default Folder X before June 1, 2015. We don’t want anyone to feel that they weren’t told about this before trying the new version.
So now – “SNEAKILY”? Really? I’ve tried to be as up-front about this as possible. Yes, I am asking you to buy a new key for Default Folder X 5. No doubt about that. It’s written everywhere. And based on the feedback I’ve gotten from the vast majority of folks out there, that’s entirely reasonable. I certainly think it is. The last time I charged for a Default Folder X upgrade was 8 years ago. Long enough that people had started sending me money out of the blue because they thought I should have charged them something by now for reliably supporting and upgrading the product for that long.
So listen folks. I’M NOT OUT TO GET YOU! Yes, I’m asking you to pay for software that saves you time and frustration on a daily basis. I’m not trying to sneak that by you. I’m not trying to dupe you. I’m not playing you for a fool. I’M RUNNING A BUSINESS. And yes, if you don’t think Default Folder X is worth as much as a meal at Denny’s, you certainly don’t have to buy the upgrade. It’s your choice – you can vote with your wallet.
Now to everyone else who’s sent me notes of congratulations, thanks, appreciation, and generally just been awesome – THANK YOU SO MUCH! You’re one of the big reasons that owning and running a small software company is so rewarding. I really appreciate your input and feedback.
Glad I got that off my chest 🙂
Tuesday, October 2nd, 2012
So after 4.5 weeks and a few prodding email exchanges back and forth with Apple, they finally got around to reviewing and approving the update for Jettison that adds support for Mountain Lion. Customers that purchased Jettison via the Mac App Store will now be notified that there’s an update and will be given the option to download it. If you’ve already visited our site and downloaded version 1.2.4, you’re up to date and don’t need to do anything more.
For more information on Jettison, or to download a demo or purchase a copy, take a look here: http://www.stclairsoft.com/Jettison/ If you prefer to find it on the Mac App Store and buy it there, by all means do so, but please be aware that you may get updates and bug fixes a month or more later if you buy it from Apple instead of through us.
Wednesday, September 12th, 2012
So, I released Jettison 1.2.3 three weeks ago. It fixed some problems that Jettison was having with Mac OS 10.8.
I simultaneously submitted version 1.2.3 to the Mac App Store, since we sell it both directly from our website and through the App Store. Then I waited for it to be reviewed and approved. And waited. And waited. Customers who purchased Jettison through the Mac App Store sent emails, asking when the update would be available for them. The version available from the web site didn’t know that they’d purchased Jettison from Apple because we’re required to use a different licensing scheme for the Mac App Store vs. our direct-sale version. “I don’t know,” I replied, “I’m waiting for Apple to review it and approve it for sale.” These customers were understandably annoyed, since the version they have doesn’t work well on Mountain Lion.
Yes, notice the present tense in that last sentence. “The version they HAVE…” Folks who bought Jettison through the Mac App Store still don’t have an update, three weeks after it was finished and submitted for review.
So I’m sick of waiting and telling our customers to wait for the update to be available via the Mac App Store. Here’s Jettison 1.2.4 – it fixes a sound problem when you’ve got your speakers muted, but more importantly, it recognizes the receipt embedded in versions of Jettison purchased through the Mac App Store. That means that people who purchased Jettison via the Mac App Store can now upgrade to this version by simply downloading a copy and running it once from the disk image before copying it to their Applications folder to replace their old copy.
I have no idea why Jettison 1.2.3’s status in iTunesConnect is still “waiting for review.” When I asked, Apple sent a non-committal email saying “Please be assured that your app has not been forgotten. Unfortunately we cannot provide an estimate of when a review will start or how long it will take to complete due to the variety of factors that contribute to the review process.” Thanks guys.
If you want real customer service and timely updates, buy software directly from the developers. We want to support our products and give you timely updates. The Mac App Store makes it harder to do that.
Monday, June 18th, 2012
Kudos to Kubra and BC Hydro – they fixed this problem within 8 hours of receiving my report and are reviewing some of their practices as well. If you’re a BC Hydro customer and have made online payments in the past, you still need to make sure to clean any of the old URLs out of your browser history.
Notice anything disconcerting about this URL?
https://secure3.i-doxs.net/BCHydro/OneTime_PayProcess.asp?PaymentDate=6%2F6%2F2012&AccountNumber=1234567&InvoiceNumber=&PayAmount=38.05& Description=&CustomerEmail=jon%40email.net&CustomerName=Jon+Gotow&PaymentType=CC& State=&ConvenienceFee=2&CCCardName=VISA&CCHolderName=Jon+Gotow& CCNumber=4123456789012345&CCCVV2=123&CCMonth=1&CCYear=15&AVSname=& AVSphone=&AVSaddress1=&AVSaddress2=&AVScity=& AVSstate=&AVSzip=
I found it in my browser history after making an online payment for a BC Hydro electricity bill. And yes, you’re not mistaken. That URL has my account number, name, email address, credit card number, credit card expiration date and CVV number all embedded in it. (Yes, I did change them before blogging about this 🙂
Honestly, this has got to be one of the biggest, dumbest security mistakes I’ve seen in ages. I mean, really? Just toss all my credit card information into my browser history in clear text? Then let Google, Apple, or Mozilla sync it to all my devices and to the Cloud – so anyone can access it anywhere – brilliant!
What’s more, clicking on that URL submits another payment directly to their system. Go ahead – click on it! You know you want to! If the numbers were still correct, you’d rack up hundreds of dollars in charges to my credit card with just a few clicks of your mouse. How do I know? Because I mistakenly did that.
The Bottom Line
Kubra, the company behind this ridiculous little payment gateway, was absolutely no help when I called. They can’t refund the payments, including their own $2 “convenience fee” – they told me to dispute the charges with my credit card company instead. And when I asked them to address the underlying security flaw, they said they couldn’t do anything without a request from BC Hydro. So I’ve contacted BC Hydro through their web site. If you’re a BC Hydro customer, I encourage you to complain to them too – and NOT pay your power bill online until they get this resolved.
And if you’ve paid a bill via Kubra in the past, go check your browser history and see if your credit card or bank information is conveniently stored there for you (and everyone else). If it is, it might be a good idea to delete it 😉
That’s Cool! How Do I Get an URL Like That?
If you’ve got a BC Hydro account, you can see this for yourself. Go to http://www.bchydro.com/ and log into your account. Click on “Ways to Pay,” then “Online banking or credit card payment,” then “Kubra” as shown below.
You’ll get a data entry screen like this. Just fill in your credit card data, click “Submit”, and then confirm your payment on the next page. Then copy the URL in your browser’s address bar or from your browser history. There you go!
* Unfortunately, you do have to enter valid credit card and account information into this window to get back a valid URL. Otherwise you just get an URL filled with error message information – not nearly as fun.
I just got a call from BC Hydro – kudos to them for moving so quickly! It’s been a mere few hours since they read the email I sent them over the weekend and they’re already moving on it.
Impressive! Kubra just called and they’ve plugged the hole on their end (it looks like the switched from HTTP GET requests to HTTP POST) so the data no longer ends up in the URL. They’re also refunding the erroneous charges caused by me going to those URLs in the first place.
So the problem is fixed! The only issue that remains: If you’re a BCHydro customer and have paid your bill online in the past, search your browser history for “BCHydro” and delete any history items that match. (That’s something that you have to fix – BCHydro and Kubra can’t erase data that’s already on your computer).
Wednesday, March 30th, 2011
Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.
Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.
Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.
I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.
Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature. Either way, the application it installed was useless. Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.
Soooo…. If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application. And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.
Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre. It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package. I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong. If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!