If you’re looking for a good AirPrint laser printer and affordable, the Samsung Xpress M2875FW is for you. There are a lot of cheap AirPrint inkjets, but due to the price of ink cartridges, I have been looking for a good laser printer.
My wish list was:
- laser printer
- multifunction (scan, copy, print)
- AirPrint support out-of-the box, to be able to print from my iPhone, iPad and MacBook Pro
- monochrome (no need to color print)
- duplex printing is not mandatory, but a plus
- affordable (less than $200: laser printers used to cost more, but the print cost of a single page is lower)
- relatively small
After a lot of researches, I’ve found a printer that answers to each point of my wish list: the Samsung Xpress M2875FW. The Samsung Xpress M2875FW is an affordable (currently $189.99 on Amazon, subject to price change) multi-function printer, with AirPrint support, duplex printing and relatively small (15.8 x 14.3 x 14.4 inches / 40.3 x 36.3 x 36.6 cm):
When doing my researches, I tried to find how good was the support of AirPrint for each possible printer. I wanted to be able to have a built-in support, and I discarded any printer that allow printing only from a third party app. If you want to be sure that you future printer will support AirPrint out-of-the-box, my advise is to check this official list of AirPrint printers by Apple.
The Amazon page of the M2875FW indicates that there is a newer model, the M2885FW, but as this newer model was not listed on the Apple AirPrint support page, I have preferred to try and buy the M2875FW. The printer has been really easy to setup (on my MacBook Pro on Mavericks), you just have to launch the Samsung install CD and follow the instructions for AirPrint. Once the printer is installed on the MacBook Pro, printing from any iPhone or iPad is immediate, with no-setup. It’s kind of magic (like all the other Air technologies, AirDrop and AirPlay).
I’m really happy with my new printer and can’t recommend it enough. The only minus point is the cost of Samsung toners, that are above the average laser toners (around 10c / page); on the other hand, the M2875FW has an eco mode, but I haven’t finished a full toner to check the real cost.
Buy the M2875FW on Amazon - affiliated link
The new issue of objc.io is about Testing. Really a good new issue with a lot of interesting stuff. Being in the iOS development since 5-6 years, I’ve seen testing to be taken more and more seriously, if not by third parties, certainly by Apple.
But, man, 8 articles on testing on iOS, and not only one mention of UIAutomation, the core Apple framework for UI testing… Really?
If you want more information on UIAutomation (now spelled UI Automation by Apple), I recommend you the top read article on our blog iOS Automated Tests with UIAutomation. It’s a little dated, but I think it’s still a good base for learning UIAutomation.
What I love about UIAutomation is that it depends on accessibility: to be able to test your user interface, you have to make it accessible. So clever!
iOS Automated Tests with UIAutomation
Launching UIAutomation Tests in Command Line
Automated Static Code Analysis with Xcode 5.1 and Jenkins
This article is really for 3D rookies like me that would like to play with SceneKit. SceneKit is a high-level 3D framework, introduced in Mountain Lion, that allows reading, manipulating and displaying 3D scenes. SceneKit is now part of iOS, starting from iOS 8, allowing developers to easily integrate 3D graphics or develop 3D casual games on iPhone / iPad / iOther.
SceneKit supports the import of COLLADA scenes: COLLADA is an open XML file format for 3D assets, supported by a lot (if not all) 3D creation softwares (like Blender, Maya, Bryce etc…). If you’re new to 3D and just want to play with SceneKit, you can search for free COLLADA files on the web (*.dae), or use the ones included in Apple SceneKit samples (Vehicle, Bananas, or even the complete WWDC 2014 SceneKit session, available as a sample code!)
Besides using free models, you can also create your own using a 3D modelling tool: there are plenty of choices from free (Blender) to very expensive (Maya). On the mac, Cheetah3D is really an excellent, and not very expensive, alternative. For $69, you have a complete 3D modelling, rendering and animation software for OSX (buy directly on Cheetah3D web site or on the Mac App Store).
I’m just beginning to use Cheetah3D, and I really appreciate how easy is the creation of 3D models. Cheetah3D is also a native Cocoa app, with an intuitive, Macintosh-like user interface:
Cheetah3D on Mavericks.
Really a great software!
I’ve created this mug in a couple of minutes, following the first tutorial of Learn 3D with Cheetah3D 6, an excellent resource on Cheetah3D. To include this model in an iOS sample app, we need to first export it as a COLLADA file from Cheetah3D. Select File > Export, choose dae as File Format and save your file (or download it here).
Then, create a SceneKit sample, with Xcode 6: New Project > Single View Application.
Give it a product name:
Select the main storyboard of the document, Main.storyboard , then the ViewController scene, and remove the default view of the ViewController.
Now, in the right corner of Xcode, select the Object library (as in the screenshot), and drag and drop a SceneKit view on the view controller.
Now, some code! Open ViewController.m and add the following code:
SCNView *myView = (SCNView *)self.view;
myView.scene = [SCNScene sceneNamed:@"mug.dae"];
myView.allowsCameraControl = YES;
myView.autoenablesDefaultLighting = YES;
myView.backgroundColor = [UIColor lightGrayColor];
We’ve just loaded our mug COLLADA file into the 3D scene view. Now, we need to import the file into our project: File > Add Files to "TestSK" and select our our mug.dae file. Then build and run:
Mmmm… Something must be missing, we don’t have any textures displayed in the simulator! In fact, we forget something really important when importing our COLLADA files from Cheetah3D. In COLLADA files, textures are referenced and not included in the file; in other terms, the mug.dae file is not sufficient, and must be accompanied by the textures files that it references. So, we just need to include our mug-diffuse.png texture in our project: File > Add Files to "TestSK" and select the mug-diffuse.png file. Before running again the sample, you can select the mug.dae file in Xcode, and check that everything looks good now:
Then, run the sample, et voilà !
The mug in the iOS simulator
More on SceneKit
WWDC 2012 - Session 504: Introducing Scene Kit
WWDC 2013 - Session 500: What’s New in Scene Kit
WWDC 2014 - Session 609: What’s New in SceneKit
WWDC 2014 - Session 610: Building a Game with SceneKit
Tab bar is a standard navigation control present in iOS, since the first introduction of the iPhone. In the iOS Human Interface Guidelines,
A tab bar gives people the ability to switch between different subtasks,
view or modes in an app.
Use a tab bar to give users access to different perspectives on the same
set of data or different subtasks related to the overall function of your
In general, use a tab bar to organize information at the app level. A tab
bar is well suited for use in the main app view because it’s a good way to
flatten your information hierarchy and provide access to several peer
information categories or modes at one time.
From gradient to flat
Tab bar has survived the iOS 7 shake-up, with minor modifications. From iOS 5 to iOS 7, the clock app tab bar’s looks like this:
Evolution of Clock’s tab bar from iOS 5 to iOS 7
Until iOS 6, tab bar icons were computed by applying a template blue gradient on a monocolor shape:
Looking closely, rendered icons also included a drop shadow and a light glowing stroke:
All third-parties apps using a tab bar exhibited the same blue bar icons (maybe with the noticeable exemption of the Nike+ app): there was no easy way using public APIs to change the icon blue rendering.
On iOS 7, the blue gradient is dropped to a flat, plain and customisable color (aka key color in iOS Human Interface Guidelines or tint color). Now, the clock tab bar looks like:
Appart from minor design modifications, the tab bar uses now two templates images for each icon: a selected/active one, and an unselected one:
The unselected icon is often just a thin silhouette of the selected icon. The selected image has more plain zone, filled with color: the attention is really focused on the selected icon. Another gain with the iOS 7 design is accessibility: even if you’re color blind, you can still see where is the selection.
Forgetting to use two different icons for the two different states is really a common mistake in a lot of iOS 7 apps (maybe due to the fact that you can’t use Interface Builder to set the image for each state). Programmatically, it’s straightforward using
NSString *imageOffName = @"ClockTabIconOff";
NSString *imageOnName = @"ClockTabIconOn";
tabBarItem.image = [UIImage imageNamed:imageOffName];
tabBarItem.selectedImage = [UIImage imageNamed:imageOnName];
iOS 6 experimentations
On iOS 6, a simple app built with the public SDK kept using the classic blue gradient. But some Apple apps showed that there were ’experimentations’ around where should go the iOS design. For instance, the App Store app used a ’flatter’ gradient, while keeping the blue selection against a black background:
App Store on iOS 5, 6 and 7
In the same time, the Music app used a completely greyed tab bar:
Music on iOS 5, 6, 7. Notice the black pixels in the bottom corners to give a "rounded" layout" in iOS 6.
Combine the new flat color selection of the App Store app and the lighter tab bar of the Music app, and we have something that can resemble to the iOS 7 aesthetic! What’s surprising is that the iOS 7 tab bar, while being a real departure from the past, has kept a familiar look and feel, and could be seen as another design iteration.
Back to basics
How to talk on tab bar and not mention Game Center? Introduced in iOS 4, Game Center (and more precisely the Game Center companion app) was the first built-in app to not use the classic blue icon / black background tab bar. It featured a rich faked wooden tab bar. Four releases latter, iOS 7 has come and put the Game Center app on the right track (more consistent, less fun):
Another proof that Apple is changing, this dedicated blog on Swift. Swift is in flux, and there are some important changes to the syntax before the official 1.0, so bookmark this official feed.
Already good advises in the second article on compatibility:
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded extension,
you will want to build the frameworks, app, and extensions together.
It would be dangerous to rely upon binary frameworks that use
Swift — especially from third parties. As Swift changes, those frameworks
will be incompatible with the rest of your app. When the binary interface
stabilizes in a year or two, the Swift runtime will become part of the host
OS and this limitation will no longer exist.
Beware of this issue: while the binary interface is not frozen, all components of your app (especially Swift framework that you don’t have the source code) should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
The idea underneath is that the code should not only compile, instead it
should "validate". Good code has several characteristics: should be concise,
self-explanatory, well organized, well documented, well named, well designed
and stand the test of time. The main goals behind the curtain are that clarity
always wins over performance and a rationale for a choice should always be
provided. Some topics discussed here are general and independent from the
language even if everything is tied up to Objective-C.
Zen and the Art of the Objective-C Craftsmanship is really a good book on Objective-C guidelines. Cocoa is full of conventions: if you’re an experienced iOS or OSX developer, you’ll already know most of these best practices; but I bet you’ll also learn two or three things you didn’t know (great discussion on blocks and retain cycles on self).
Luca and Alberto started writing this book on November 2013. But now Swift is the future of Mac and iOS development so they decided to release the current version of their book. Great work (via Dave Verwer’s iOS Dev Weekly).
Quite funny, we just have this discussion this morning: we ask ourself if one should propose a Facebook or Twitter login while designing a new login page. MailShimp in Social Login Buttons Aren’t Worth It gives some really good reasons (and analytics) not to use social login buttons:
Sometimes you log in with Twitter, sometimes with Facebook, sometimes with
a username and password specific to that app. It’s hard enough to remember
your username and password, let alone which service you should bloody use
to log in. As you add login buttons to a page, you also add decision points
for users, while creating visual complexity in your design. The marginal
gains in login rate are chipped away by the additional cognitive load you’re
adding for your users.
Is it worth it? Nope, it’s not to us.
Mike Stern, Apple User Experience Evangelist in Designing Intuitive User Experiences - 211 WWDC 2014 session (at 31’ 57"):
But I feel like I would be remiss If I didn’t use this opportunity to talk
with you about hamburger menus. AKA Slide out menus, AKA sidebars, AKA
basements, AKA drawers.
Now, these controls are very common on iOS, and on other platforms. And I’m
sure many of you here work on apps that have these. You guys made the decision
to put it in your app. And I’m sure that you did so with the very best of
intentions. And I will say that these controls do a couple of things very
For one thing, they save space. So rather than taking up a bunch of room at
the bottom of the screen for a tab, you’re just taking up a little bit of area
in the top left corner for the hamburger menu.
And you practically have the
entire height of the screen to show options to people, and if that’s not
enough, you’re going to cram more awesomeness into your app, people can
But, this is - I actually haven’t played around with the latest version of
Xcode, so I really hope that they haven’t changed this - I don’t believe you’ll
find a hamburger menu controller inside of Xcode.
Now, typically we don’t provide design advice about the things that we don’t
offer to you guys, but I can’t help myself, right? I’ve so many conversations
with people about this control, spending hours and hours talking about it, and
you know, I think it’s important that we talk about it here today.
And again, I’m not going to say that there’s no place for these controls
categorically. I think there are some apps that could maybe use one. But I
will say that their value is greatly over-stated, and they have huge usabiliy
Remember, the three key things about an intuitive navigation system is that
they tell you where you are, and they show you where else you can go.
Hamburger menus are terrible at both of those things, because the menu is not
on the screen. It’s not visible. Only the button to display the menu is.
And in practice, talking to developers, they found this out themselves.
That people who use their app don’t switch to different sections very
frequently when they use this menu. And the reason for that is because the
people who use their app don’t know where else they can go. Right? They don’t
know because they can’t see the options, or maybe they saw it at one point in
time, but they have since forgotten.
And if you use this control, you have to recognize that the people who use your
app may not realize the full potential of your app.
Hamburger menus are also just tedious, right? If you want to switch sections
from the Accounts tab to the Transfers tab, all you need to do is tap the
button and you’re there instantly, and if you want to go back, you tap the
account button, and you’re back where you started from.
Doing the same thing with the hamburger menu involves opening the menu,
waiting for the animation to finish, re-orienting yourself, finding the option
you’re interested in, tapping that, and then waiting for the animation to
complete, getting back to where you were before, and if you want to go back,
you have to open the menu again, go through that whole process, and there you
It takes at least twice as many taps to change sections. Something that should
be very easy and fluid is made more difficult.
And the other thing the hamburger menus quite frankly do badly is that they
don’t play nicely with back buttons. Right? I’ve seen this a lot. Back buttons
are supposed to go in that top left corner position, but instead there’s this
hamburger menu there, so people put the back button right next to it, but no
longer does this look like a back button anymore, it just looks like this
arrow which is pointing to the hamburger menu, looks ridiculous, and sometimes
people recognize that it looks ridiculous so when you drill down into the
hirerarchy of an app, the hamburger menu goes away. Now it takes even more
steps to switch to a different section. You have to go back up enough times
to get to a level in the hierarchy of an app to get to a view that contains
the hamburger menu.
Now, sometimes people will try to solve this by putting the menu on the
right-hand side, but that’s not advisable either. That location is a really
important location. Usually, you can put some kind of action there, you know,
like a plus sign to add something, or an edit button.
And finally, the downside of being able to show a lot of options is that you
can show a lot of options. Is that you will show a lot of options. The
potential for bloat and misuse is tremendous. They allow you to add all sort
of stuff that your users don’t really care about. Like information about the
app. Or version history, or credits. I hate to break it to you, but no one
And the other thing is that people wind up taking ads and special offers and
making them look just like regular sections and putting it in there too. That
sucks. No one wants that either. Look, drawers of any kind have a nasty
tendency to fill with junk.
Okay, let’s move on. [ Applause ]
Apple could not be clearer: don’t use hamburgers menus on iOS.
Luis Abreu on Why and How to avoid Hamburger Menus:
The Sidebar Menu pattern welcomes bad IA because you can simply add one more
thing to it without a direct consequence — that is until people actually use
This is really my main grip against hamburger menus: with this slide menu, you’ve a place where you can cram any stuff you want instead of focusing on your main app features.
The opposite of design in fact (on iOS, I’ve never seen an Apple app using one).
Some goods links at the end of the article:
We now have data that suggests Sidebar menus—sometimes called Hamburger
Menus/Basements—might be causing more harm than good.
The OSX "Open With" menu can sometimes be clustered with duplicates. To remove them, close all Finder windows, open a terminal and type:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
Done (works on Mavericks and +).
This has been the most important WWDC since the introduction of the iPhone SDK, 6 years ago.
On the really incredible amount of new features, for both developers and users, I will highlight two things:
1: App Extensions. Think of it as a mini version of your app that can be opened in the context of an another app. Today, in Safari, you can share links with Twitter and Facebook: when you share an URL, a small dialog appears, this is an extension of Twitter or Facebook, inside Safari. With iOS 8, any app can appear in this sharing menu and have a small interface inside Safari, to process the current web page. This is not limited to Safari, but in fact any apps can use extensions provided by your app. It’s really a secure and easy way to seamlessly share datas between apps.
I think that App Extensions will completely modify the way we use and develop apps, a lot of new features are now possible: we stand today on the edge of a New Frontier for iOS!
2 : Swift, of course. I really like Objective-C, the grammar is very small, and there has been a number of really good additions to streamline the development like ARC and Objects literals. Now, we have a brand new language, designed to be the iOS / OSX developers lingua franca for the next 10-15 years, and I’m a little scared! Swift looks modern and brilliant with function as first class citizens, a REPL, inferred type, a powerful case pattern matching, tupples etc… But it’s the unknown…
We’re at the Year Zero of this new language and I’m a little afraid to leave behind me a really good friend.
And, of course, I’m also excited: it’s so good to be an iOS developer!