Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts published in August, 2014

The direct download version of RB App Checker Lite 1.1 (281) is out, and RB App Quarantine also has been updated to build# 281 (its version is still 1.1 since nothing has changed for the user). Check out the release notes!

Most important: this version of RB App Checker Lite considers the new signing rules in TN2206 for OS X 10.9.5 and 10.10. In particular, for applications, code signatures are now checked recursively, both version 1 and version 2 resource rules are shown if present, and the spctl utility is called to check the Gatekeeper assessment.

However, this signals a new development: direct download and Mac App Store versions of RB Utilities will now, unfortunately, have different functionality. In particular, the MAS version of RB App Checker Lite (which is currently in review) will not be allowed to call  spctl, as this utility requires special entitlements to work; and the MAS version of RB App Quarantine (also in review), for the same reason, will not clear the quarantine flag. So for now you may want to download directly from the product pages.

Apple’s rules for calling attention to such differences are a little tricky to navigate but hopefully the MAS versions will be approved and in a future release I’ll develop a way to bring this functionality back through an optional download. Research is underway!

RB App Quarantine 1.1 (273) is out. It’s the second app in the RB Utilities software suite — RB App Checker Lite was the first one.

As the name implies, it’s a utility that checks or changes the “quarantine” attribute of other applications. This attribute is set whenever an application is directly or indirectly downloaded by the user from anywhere except the Mac App Store. (Applications produced from installer packages, disk images or compressed files inherit the attribute automatically.)

When a quarantined application is first opened or executed, OS X’s Gatekeeper function will check the application’s code signature and several other details and either reject it or throw up the well-known dialog, confirming that you want to execute a downloaded application. If you agree, the quarantine is cleared and Gatekeeper will not check the application again.

Using RB App Quarantine to clear some just-downloaded application’s quarantine attribute is not really recommended: you’ll be bypassing Gatekeeper and — unless you’re a developer yourself and/or have already used RB App Checker Lite to check that application’s bona fides — may be opening your system to a potentially untrusted application.

If you are a developer yourself, using RB App Quarantine to set quarantine on your own application will allow you to check its Gatekeeper status without using Terminal commands or (perish forbid) uploading it to some server and downloading it again.

It took me just 5 days to write this little application since all the UI and other logic common to all RB Utilities is contained in a prepackaged framework and I just had to write the app-specific file/folder handling. Setting up a new project with everything in place and drawing the new icon took a single day. Unfortunately clearing the quarantine attribute takes a special sandbox entitlement which would certainly be frowned upon by the Mac App Store reviewers, so I didn’t even try submitting it.

In other news, I submitted a new version of RB App Checker Lite to the Mac App Store and, if everything goes well, it should be out soon. This new version fixes some bugs and — most requested by users — shows some details pertaining to the latest version of Apple’s Technote 2206, namely showing version 1 and 2 resource rules and showing the Gatekeeper (spctl) assessment results. Stay tuned…

A few days ago, at the monthly CocoaHeads meeting here in Belo Horizonte, I was asked to do a brief talk. Since I didn’t have anything ready on short notice, I said I could show off my SwiftChecker app and do an informal Q&A about Swift.

It turned out that most of the attendees were new to Cocoa programming and none had yet done anything in Swift, so I mostly confined myself to the Q&A part. Here are some of the questions — not necessarily in order, and expanding somewhat upon my answers.

Q: we’ve landed a contract to do an iOS app. Won’t it be faster or more efficient to learn Swift now, instead of Objective-C?

A: absolutely not! (echoed by all present that had apps published) You should learn Swift now, it’s a new thing; we’re all starting out together, you’ll gain experience and you can even submit suggestions. But write apps for yourself, nothing that depends on a deadline. In any event, you won’t be able to deliver anything until the final Xcode 6 is out in a few months. In any event, in any real-world app, some parts may remain that are better done in Objective-C; and to understand Cocoa and other frameworks, Objective-C is a necessity. Ask me again in two years — it may be different then.

Q: is Swift interpreted like JavaScript, or compiled to a virtual machine like Java, or native?

A: it’s native. Compilation is a little unusual in that you have a simple parser in front, then you get an intermediate representation which goes to a front-end optimizer — this converts all syntactic sugar into library calls, and most of the language is implemented in the library — then that outputs the standard LLVM intermediate representation, which then goes through the same back-end optimizer and code generator that Clang uses. But at the end it’s native. The REPL/playground does some of that to fool you into thinking it’s interpreted, but that’s mostly for learning and trying out things.

Q: so how much do you use the playground? Is it true that it’s still unstable?

A: yes, it’s unstable and there are bugs inherent to the mode the playground compiles stuff, so I’ve never used it. My style is to start with a very simple app — even a command-line app — and gradually build it up.

Q: I began learning Objective-C a year ago and I still haven’t got used to the brackets. What do you similarly dislike in Swift?

A: I remember getting used to the [ ]s in two weeks after I discovered they could be nested; what I never got used to, even after 14 years, is that method and function declarations used different syntax — at least they fixed that! In Swift what I find strange is using dot syntax everywhere. I was a late adopter of it in Objective-C, and usually for properties only. I’m still typing semicolons and backspacing immediately, or putting the type first in declarations, but so far that’s just my habits, not an annoyance with the language.

Q: the first thing I noticed in beta 1 was that there was no private.

A: well, they put that in now; I suppose it’s important to you guys who work in teams, but I don’t like hiding things from myself. (Someone: “and exceptions?”) I’ve never needed exceptions for my applications, but better error handling is supposed to be coming soon.

Q: which is more fun to write in, Swift or Objective-C?

A: depends on how you define “fun”. Writing Swift takes some learning and you have new, powerful constructions like extensions and optionals — but in Objective C you can do fun things with dynamic dispatching or go down into C and do tricky things with pointers and memory. Ideally you should learn both. In general I’m in favor of learning also the lower levels, even machine language; it will help you with debugging.

Q: do you think Swift means that Apple is now abandoning imperative languages and adopting a more functional programming approach?

A: I think those are largely academic concepts — not in the sense that they’re unimportant, but in the end it comes out to what you need in practice to do a specific job. When I studied computer science, “structured programming” was the fashion of the day. Later on “object orientation” arrived and contained many of the older precepts. Now “functional programming” is in fashion, but Swift still has objects (and even structures in the sense of if/then/else, for and while loops, etc). So you can adopt different fashions when programming in Swift, but pragmatism is very important — use them only where appropriate.

Expanding upon that. Swift certainly isn’t a pure functional language to the extent that you can say that of Haskell (read this excellent article for details). Swift isn’t a pure object-oriented language either, neither in the C++ sense, nor in the Objective-C sense, nor in the Java sense – it has both structs and classes, both static and dynamic dispatch, but its functions, closures and generics allow you to do some functional stuff. It’s not a descendant of C because it has no pointers, no header files, no macros. It’s not a descendant of C++ because generics aren’t templates, although they use <>s. It’s not a JavaScript/PHP-like scripting language — I was shocked to hear someone describing it as such, just because it has type inference and a REPL.

So the answer is, it’s a new language, it tries to be very consistent and pragmatical, and it has imperative, functional, and object-oriented features.  It can’t be all things to all people, at least in the first versions. Don’t try to fit your existing patterns into it, rather build and learn new patterns — of course there are some rewriting their Scala patterns (or STL, or whatever) in Swift so they can go on using the names/patterns they’re used to, but that’s like moving to an exotic country and asking for your usual breakfast: unrewarding in the long run.

Sidenote: I’d never heard of functional programming until a few years ago, when I had to learn about map/reduce for an interview with Google; when that didn’t work out, I forgot all about it until Swift came out. It’s quite interesting (see this article, for instance) and I see how it can be useful for many things; still, in Swift you’re free to mix all these paradigms, which is quite enough for my purposes.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2017 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.