What is Differential Privacy?

One of the notable concepts to emerge from Apple’s World Wide Developers Conference in San Francisco this year, has been the notion of differential privacy. As Wired puts it Differential Privacy is the “…statistical science of trying to learn as much as possible about a group while learning as little as possible about any individual in it.”

Introduction

One of the notable concepts to emerge from Apple’s World Wide Developers Conference in San Francisco this year, has been the notion of differential privacy. As Wired puts it Differential Privacy is the “…statistical science of trying to learn as much as possible about a group while learning as little as possible about any individual in it.” 

Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless.

Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails. (source: Google)

The premise of differential privacy lies in that the reports are indistiguishable, the random coin flips have no unique identifiers, yet the aggregation of reports allow us to share common results shared by many users. With companies like Facebook and Google constantly receiving flack for compromising user privacy in lieu of the value of selling customer insights, and user-targeted advertising, Apple are more-or-less perceived as the beacon when it comes to championing user privacy. Differential Privacy is Apple’s answer as the industry embeds itself more and more in mobile and wearable renaissance, especially with location-capable devices making privacy-invasiveness more frequent. 

Whilst Apple have never had a great interest in user data, compared to the others, as it slowly and publicly revealed its intentions to work with big data, to improve Siri’s contextual knowledge, instead of going the Google-way, it has instead opted for the sliding-scale modelof differential privacy. 

“People have entrusted us with their most personal information. We owe them nothing less than the best protections that we can possibly provide.” (Tim Cook, White House Cybersecurity Summit, ’15).

As consumers become more security and privacy-conscious, in light of the NSA and other global revelations, it has never been more imperative that companies and developers recognize the importance of safeguarding user information. Great applications do that through the following criterion:

  1. Transparency in storage and use of personal data;
  2. Consent and Control of what personal data is made available;
  3. Security and Protection of personal data, through encryption;
  4. Use Limitation, to only what is required, at the time that it is required.

This article will dive into why it is vital that developers adopt it, and subsequently, ways in which you can implment it it in your iOS app. 

WHAT IS DIFFERENTIAL PRIVACY?

Differential Privacy is in fact an obscure branch of mathematics that aims to analyze a group more, whilst annonimizing individual users. The thesis was aithored by Professor Aaron Roth of the University of Pennsylvania, and Apple has not only embraced this as a service that will flow through its own services, but strongly advocating it for its third-party developer community. 

“The concept behind differential privacy is the idea of obscuring or introducing ”noise“ into big data results to mask individual inputs while still getting useful information on larger trends ” according to Roth (as cited in AppleInsider), ensuring that individual information is not revealed, but still gaining a sample representation, for statistical purposes. 

Apple has already started roilling out differential privacy on their apps and services, starting from iOS 10. On their messaging app, Apple is better predicting user input based on words used via aggregated big data. Apple has improved its search suggestion feature, where it previously ensured all Spotlight data was stored only locally, with developers deciding what data to share in spotlight (through indexing). 

With the latest iOS iteration, users will choose whether to submit more public data about their activities, and Apple adds random noise to make it impossible for data to be traced back to single users. 

Differential privacy addresses anonymity by providing enough information about a crowd, without the association of the individual, but with enough answers the noise of randomness could deduce through calculation to produce a relatively accurate distribution. There are some problems that are inherent with differential privacy

LEVEL OF DATA COLLECTED

Data is partially recoverable, depending on on how much data from an individual party is collected. Apple resolves this through sending a subset of data (a small sample), similar to exit polls in elections, representing the intended distribution. 

Suppose you have access to a database that allows you to compute the total income of all residents in a certain area. If you knew that Mr. White was going to move to another area, simply querying this database before and after his move would allow you to deduce his income. The answer is to create an approximation of the total income, getting accurate information whilst protecting Mr White. (source: (Neustar))

LEVEL OF NOISE USED TO OBSCURE DATA

Another issue, as we had pointed out, what if there are only a few users, or a small sample, due to the size of the distribution? How much noise should be used to obscure data? Apple when adding noise, also disregard some data on a regular basis, whilst other get uploaded, meaning data is transient, rather than historically emperical, adding more weight to the noise aspect. 

“Users can opt to not send any data at all, he says, and Apple will additionally discard IP addresses before storing information on its end to avoid connecting even noisy data with its origin” (source: Macworld)

The level of noise is adjusted depending on the density of the sample, such as if there are only two or three users, you will want to adjust your noise more, to ensure that the data count never deduce back to any individual user. If say there are only one or two people in a village, Apple will introduce noise, ensuring you know the frequency but not the whom

LEVEL AND FREQUENCY OF THE SAME QUESTION ASKED

Asking users the same question, or even similar questions across a specific time-period can also lead to the de-anonymity of data. 

…asking too many similar questions, matters become more subtle. If you ask someone if they’re a member of the Communist party, and then ask if they admire Joseph Stalin, and then ask the ideal economic and political system, and so on, it’s possible an outside observer would eventually penetrate through the noise and determine an attitude on a given topic…. (source: Macworld). 

This leads us to the subject of privacy budget.

Privacy Budget

Privacy budget is the notion of limiting how much data from the same (or related subject) is transmitted over a period of time. Premised with the fact that asking the same question over and over again over a short period of time, and getting the same answers could lead to determining the truthful answerprivacy budgets are scales that developers work with to balance the reliability of collected and aggregated data against the prospects of re-identification

This is a complicated mathematical theory in itself, which is best illustrated in Anthony Tockar’s research paper. Suffice to say, the privacy budget measurement is a more important control measure than the statistical upper bound of a query, so that once a query budget is exceeded by the user, the user will not be able to make any further queries. This is what essentially defines diffrential privacy and privacy budget.

Other Measures to Secure User Data

I mentioned at the start of this article, the four important aspects that amount to the secure guardianship of your user’s data, together with differential privacy

TRANSPARENCY

Users demand transparency when it comes to how their information is stored and used, so providing disclaimer to that effect is imperative, as a good model citizen developer. They still own their information, giving you access to their information means they need to understand how you plan on using their data.

In iOS 10, Apple’s Advertising network has an icon that allows users to see how some of their non-identifiable data made the ad relevant. 

 

CONSENT & CONTROL

0*7e0CKegCmLHKbpWM.png

This leads onto consent and control, giving users the ability to consent as to whether they want to give you information, and how much information to give you, as well as the ability to rescind their permissions. This should be explicit, and iOS for the most part provides an easy way for you to ask permission before you access their personal information, be it address bookphotos librarylocation and so on. 

Whilst system settings affords users the right to revoke permissions, you should make it easier, by including in your app, menu settings that allow for toggling as well as adjusting different permissions, in an easy way. Most importantly, if the user does rescind permissions, they don’t get a poorer experience, but instead get a less identifiable experience. 

 

SECURITY & PROTECTION

Of course, it goes without saying that the information you take consentually should always be securely stored, through enryption, using best-practices. If you are unable to provide strong encryption, don’t store personal information, its a simple as that. If there is a breach, as has been the case with numerous companies, like LinkedIn, reset user’s passwords immediately and provide them with notice, expeditiously. 

USE LIMITATION

Finally, use limitation refers to only taking what you need, not what you want, in a timely manner. Understand what statistics you need, and take only the attributes that make that, rather than setting a blanket Facebook permissions box that asks for everything, in the hope that some of it may be useful to you. 

Conclusion

Differential Privacy is a highly theoretical mathematical concept, that was devised some few years ago, but with privacy front-and-center in people’s minds, Apple have decided to make this part of their platform for iOS 10 and beyond, despite there not being widespread proof that this works in practice. Safeguarding user privacy, Apple have nevertheless placed a lot of trust and effort to push this initiative. 

Through privacy budget, this methodology promises to gather crowd information without distinguishing individual users, through the addition of noise, as well as through the sampling of smaller subsets of distributions. 

This is a very interesting area, and with Google also expressing an interest in the theory, we may see this as the future industry-standard. In fact, this may eventuate to the arms of governments where future legislation may entrust companies with stricter compliances. On a final note, I would recommend watching Apple’s Engineering Privacy for your Users WWDC session, which provides an excellent insight into Apple’s take on the theory. 

Citations and References

Motion is Emotion: Prototyping Microinteractions for Apple Watch with Framer Studio

I wanted to share an interesting article on Prototyping for smaller devices, known as MicroInteractions.

This article by GrandCentrix shows how to get the interaction you want, on paper, before doing it using scripts, to be able to display and mimic it in a presentation format:

Static wireframes are perfect for getting your information architected. But when it comes to bringing your app to life, you have to prototype the motion. Why? Because motion is emotion. And you can quote me on that.

Whether a coiling bar, a fluidic zoom, a physically realistic bounce, an amusing animation – movement brings apps to life. And interestingly enough, there are countless ways to design for even the simplest of interactions.

Prototyping microinteractions will be even more important when you’re designing for small interfaces like Apple Watch. And that became apparent to me the day we anxiously huddled around our conference room here at grandcentrix to watch Apple present its latest children to the world:

We conceived, designed and developed Apple Watch as a completely singular product. You know, you can’t determine a boundary between the physical object and the software.

So how do you blend the boundary between the physical and digital?

Forget about those ultra long text descriptions of complex transitions like this:

On load: The individual bars representing a degree fly into view from the left with such momentum that they spring back and forth until coming to rest in their final position. The appearance of each bar is staggered with the bottom bar appearing first in such a way that the entire column of bars moves like a Slinky.

Start using prototyping tools like Framer Studio or Origami with Quartz Composer or even Keynote to show what you mean.

By focussing on motion, you can

  • suggest hierarchy or relationship between elements or views
  • provide feedback for some tap, press, swipe or dial
  • show a state change
  • amuse the user

For more information, go to: Motion is Emotion: Prototyping Microinteractions for Apple Watch with Framer Studio.

__attribute__ directives in Objective-C | Twitter Engineering Blog


learn-64058_640learn-64058_640

I’ve decided to include a great article from the Twitter Engineering Blog on __attribute__ directives.

In this post, we’ll examine what __attribute__ directives are and how they can be used in development. The goal is to establish a value to using __attribute__ directives in any codebase and to provide a starting point with some directives that anyone can start using right away.

  1. What are __attribute__ directives?
  2. When should I use an __attribute__ directive?
  3. Recognizing the dangers of misusing an __attribute__ directive
  4. Core __attribute__ directives
  5. ARC __attribute__ directives
  6. More __attribute__ directives
  7. in, out and inout
  8. __attribute__ directives as a tool
  9. __attribute__ resources

What are __attribute__ directives?

The __attribute__ directive is used to decorate a code declaration in C, C++ and Objective-C programming languages. This gives the declared code additional attributes that would help the compiler incorporate optimizations or elicit useful warnings to the consumer of that code.

Better said, __attribute__ directives provide context. The value of providing context to code cannot be overstated. Developers have provided context by way of explicit declarations and comments since before the advent of the integrated circuit, but the value of providing context that can be evaluated by a compiler gives us a whole new level of control. By explicitly providing the confines of how an API behaves to the compiler, a programmer can gain some tangible benefits. The directives can be used to enforce compliance with how other programmers consume that API. In other cases, __attribute__ directives can help the compiler to optimize – sometimes to large performance gains.

As Matt Thompson cogently put it in a blog post: “Context is king when it comes to compiler optimizations. By providing constraints on how to interpret your code, [you’ll increase] the chance that the generated code is as efficient as possible. Meet your compiler half-way, and you’ll always be rewarded… [It] isn’t just for the compiler either: The next person to see the code will appreciate the extra context, too. So go the extra mile for the benefit of your collaborator, successor, or just 2-years-from-now you.” Which leads nicely into wise words from Sir Paul McCartney, “and in the end, the love you take is equal to the love you make.”

When should I use an __attribute__ directive?
Whenever you have an opportunity to provide additional context to a code declaration (variable, argument, function, method, class, etc), you should. Providing context to code benefits both the compiler and the reader of the API, whether that’s another programmer or yourself at a future point in time.

Now let’s be practical for a moment too. There are dozens of __attribute__ directives and knowing every single one of them for every single compiler on every single architecture is just not a reasonable return on investment. Rather, let’s focus on a core set of commonly useful __attribute__ directives any developer can take advantage of.

Recognizing the dangers of misusing an __attribute__ directive
Just as poorly written comments and documentation can have consequences, providing the wrong __attribute__ can have consequences. In fact, since an __attribute__ affects code compilation, affixing the wrong __attribute__ to code can actually result in a bug that could be incredibly difficult to debug.

Let’s take a look at an example of where an __attribute__ directive can be misused. Let’s suppose I have an enum that I use pretty often and frequently want a string version for it, whether it’s for populating a JSON structure or just for logging. I create a simple function to help me convert that enum into an NSString.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Header declarations
typedef NS_ENUM(char, XPL802_11Protocol) {
    XPL802_11ProtocolA = 'a',
    XPL802_11ProtocolB = 'b',
    XPL802_11ProtocolG = 'g',
    XPL802_11ProtocolN = 'n'
};
FOUNDATION_EXPORT NSString *XPL802_11ProtocolToString(XPL802_11Protocol protocol);
// Implementation
NSString *XPL802_11ProtocolToString(XPL802_11Protocol protocol)
{
    switch(protocol) {
        case XPL802_11ProtocolA:
             return @"802.11a";
        case XPL802_11ProtocolB:
             return @"802.11b";
        case XPL802_11ProtocolG:
             return @"802.11g";
        case XPL802_11ProtocolN:
             return @"802.11n";
        default:
           break;
    }
    return nil;
}

So I have my great little converting function and I end up using it a lot in my code. I notice that my return values are constant NSString references and are always the same based on the protocol that is provided as a parameter to my function. Aha! A prime candidate for a const __attribute__ directive. So I just update my header’s function declaration like so:

1
FOUNDATION_EXPORT NSString*XPL802_11ProtocolToString(XPL802_11Protocol protocol)__attribute__((const));

And voilà! I have just provided context to any consumer of this function such that they know that the return value is completely based on the provided parameter and won’t change over the course of the process’ life. This change would also provide a performance boost, depending on how often the function is called, since the compiler now knows that it doesn’t actually have to re-execute this function if it already has cached the return value.

Now, let’s say one day I notice the enum value is the character of the protocol and I decide to be clever and change my implementation to something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
NSString *XPL802_11ProtocolToString(XPL802_11Protocol protocol)
{
switch(protocol) {
    case XPL802_11ProtocolA:
    case XPL802_11ProtocolB:
    case XPL802_11ProtocolG:
    case XPL802_11ProtocolN:
       return [NSString stringWithFormat:@"802.11%c", protocol];
    default:
       break;
  }
      return nil;
}

Now since I failed to remove the const attribute, I have just introduced a massive bug that could easily crash my app. Why? Well, the key difference is that the return value of my function is no longer a constant reference. When we were returning hard coded strings before, the compiler stored those strings as persistent memory and those NSStrings effectively had a retain count of infinite. Now that we dynamically generate the string based on the protocol’s char value, we are creating a new string every time – and that means memory that changes. The reference returned in one call to the function won’t actually be the same reference as a subsequent identical call. The problem will rear it’s head when the compiler optimizes subsequent calls to that function to just immediately access what the compiler considers the known return value, which would be the reference returned by the original call. Sadly, that reference has likely been deallocated and potentially reallocated by some other memory allocation by now. This will lead to our application crashing on either a bad memory access or an invalid method call on the object that occupies that reference’s memory. The worst of this is that the optimization that would cause this crash will only happen in builds that are highly optimized. Since debug builds often have optimizations turned down, you can run your app in a debugger forever and never reproduce it, making this bug, like most __attribute__ based bugs, very hard to figure out and fix.

This is bug effectively boils down to treating a function that returns transient memory as const. The same goes for functions or methods that take transient memory as a parameter. Easy enough to remember is that any function returning a pointer return value must return a constant reference to use the const __attribute__ directive and absolutely no const function can have a pointer (including an Objective-C object) as a parameter.

Now this example is merely a precaution for using __attribute__ directives and shouldn’t deter you from using them in your code. If you stick to __attribute__ directives you understand and pay attention to how they are used, you’ll be able to steer clear of these bugs and harness the power __attribute__ directives were meant to provide. Just remember, when in doubt, don’t attribute, because providing the wrong context is worse than providing no context.

To point you in the right direction, below is a compiled list of useful attributes that should be more than enough to improve any developer’s tool belt.

Core __attribute__ directives
__attribute__((availability(…))), NS_AVAILABLE and NS_DEPRECATED

Indicate the availability of an API on the platform

NS_AVAILABLE: Apple macro for attributing an API as available in a given OS release. NS_AVAILABLE_IOS(available_os_version)

NS_DEPRECATED: Apple macro for attributing an API as deprecated in a given OS release.

NS_DEPRECATED_IOS(available_os_version,deprecated_os_version)

  • Use NS_AVAILABLE and NS_DEPRECATED macros to hide the complexity of this attribute.
  • Commonly used when deprecating one API and adding a new API as a replacement.
  • When creating a new API for backwards compatibility, immediately attribute the API as deprecated and include a comment on the API that should be used for current OS targets.
  • These directives are tied to the operating system version and cannot be used for framework versioning. For those instances, use __attribute__((deprecated(…)).
1
2
3
4
5
6
7
8
9
FOUNDATION_EXPORT NSString * const MyClassNotification NS_AVAILABLE_IOS(3_0);
FOUNDATION_EXPORT NSString * const MyClassNotificationOldKey NS_DEPRECATED_IOS(3_0, 7_0);
FOUNDATION_EXPORT NSString * const MyClassNotificaitonNewKey NS_AVAILABLE_IOS(7_0);
NS_AVAILABLE_IOS(3_0)
@class MyClass : NSObject
- (void)oldMethod NS_DEPRECATED_IOS(3_0, 6_0);
- (void)newMethod:(out NSError * __autoreleasing *)outError NS_AVAILABLE_IOS(6_0);
@end

__attribute__((deprecated(…))) and __attribute__((unavailable(…)))
Indicates that an API is deprecated/unavailable.

__attribute__((deprecated(optional_message)))
__attribute__((unavailable(optional_message)))

In case you don’t want to use the availability attribute for deprecation.

1
2
3
4
5
- (void)deprecatedMethod __attribute__((deprecated));
- (void)deprecatedMethodWithMessage __attribute__((deprecated("this method was deprecated in MyApp.app version 5.0.2, use newMethod instead"));
- (void)unavailableMethod __attribute__((unavailable));
- (void)unavailableMethodWithMessage __attribute__((unavailable("this method was removed from MyApp.app version 5.3.0, use newMethod instead"));

__attribute__((format(…))) and NS_FORMAT_FUNCTION

Indicates that a function/method contains a format string with format arguments.

__attribute__((format(format_type, format_string_index, first_format_argument_index)))
format_type: one of printf, scant, strftime, strfmon or __NSString__

Reminder: argument indexes when specified in an attribute are 1 based. When it comes to Objective-C methods, remember they are just C functions whose first 2 arguments are the id self argument and the SEL _cmd argument.

  • NS_FORMAT_FUNCTION: macro provided by Apple for __NSString__ type format string
  • Use NS_FORMAT_FUNCTION macro when attributing a method/function with an objective-c string for formatting.
1
2
3
4
FOUNDATION_EXPORT void NSLog(NSString *format, ...) NS_FORMAT_FUNCTION(1,2);
void MyLog(MyLogLevel lvl, const char *format, ...) __attribute((format(printf, 2, 3)));
// ...
- (void)appendFormat:(NSString *)format, ... NS_FORMAT_FUNCTION(3, 4);

__attribute__((sentinel(…))) and NS_REQUIRES_NIL_TERMINATION

Indicates that a function/method requires a nil (NULL) argument, usually used as a delimiter. You can only use this attribute with variadic functions/methods.

__attribute__((sentinel(index))

index: the index offset from the last argument in the variadic list of arguments.

__attribute__((sentinel)) is equivalent to __attribute__((sentinel(0)))

You’ll almost always want to use the NS_REQUIRES_NIL_TERMINATION macro

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Example 1
@interface NSArray
- (instancetype)arrayWithObjects:... NS_REQUIRES_NIL_TERMINATION;
@end
 
// Example 2 - of course you'd never do this...
NSArray *CreateArrayWithObjectsWithLastArgumentIndicatingIfArrayIsMutable(...) __attribute__((sentinel(1)));
 
void foo(id object1, id object2)
{
    NSArray *weirdArray = CreateArrayWithObjectsWithLastArgumentIndicatingIfArrayIsMutable(object1, object2, nil, YES);
    NSAssert([weirdArrayrespondsToSelector:@selector(addObject:)]);
    // ...
}

__attribute__((const)) and __attribute__((pure))
__attribute__((const)) is used to indicate that the function/method results are entirely dependent on the provided arguments and the function/method does not mutate state.
__attribute__((pure)) is almost the same as its const counterpart, except that the function/method can also take global/static variables into account.

  • Though adding the const or pure attribute to an Objective-C method is not as useful to the compiler due to the dynamic runtime, it is still VERY useful to a programmer reading an interface.
  • It is recommended that all singleton instance accessors use the const attribute.
  • The optimization upside of accurately using this attribute can be an enormous win. If you have an Objective-C class method that is frequently used and is const or pure, consider converting it into a C function to reap some serious benefits.
  • On the flipside, using this attribute incorrectly can lead to a nearly impossible to locate bug as actually seeing the redundant use of the function removed by the compiler requires looking at the assembly! Oh, and this type of bug will rarely show in a debug build since only highly optimized builds will have the bug.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// Example 1: Singleton
@interface MySingleton : NSObject
+ (MySingleton *)sharedInstance __attribute__((const));
@end
// Example 2: Function overhead optimization
// Get the description of a specified error number
const char *StringForErrNo(int errorNumber) __attribute__((const));// strerror(errorNumber)
// Get the description of the global errno error number
const char *StringForGlobalErrNo(void) __attribute__((pure)); // strerror(errno)
void DoStuffWithGlobalErrNo()
{
      NSLog(@"%@ %s", [NSStringstringWithUTF8String:StringForGlobalErrNo()],StringForGlobalErrNo());
      printf("%sn", StringForGlobalErrNo());
      printf("%in"strlen(StringForGlobalErrNo()));
}
// will compile as something more like this:
void DoStuffWithGlobalErrNo()
{
const char *__error = StringForGlobalErrNo();
NSLog(@"%@ %s", [NSString stringWithUTF8String:__error], __error);
     printf("%sn", __error);
     printf("%in"strlen(__error));
}
// which effectively eliminates both 1) the overhead of the function call and 2) the internal execution cost of the function
// Example 3: Function execution cost optimization
int nthFibonacci(int n) __attribute__((const)); // naive implementation to get the nth fibonacci number without any caching
void TestFibonacci()
{
     time_t start = time(NULL);
     int result1 = nthFibonacci(1000); // execution time of D
     time_t dur1 = time(NULL) - start; // some large duration D
     int result2 = nthFibonacci(1000); // execution time of 1
     time_t dur2 = time(NULL) - start; // same as dur1, duration D
     int result3 = nthFibonacci(999); // execution time of ~D
     time_t dur3 = time(NULL) - start; // duration of 2*D
// The __attribute__((const)) directive can effectively eliminate a redundant call to an expensive operation...nice!
}

 

__attribute__((objc_requires_super)) and NS_REQUIRES_SUPER
Indicate that the decorated method must call the super version of it’s implementation if overridden.

  • Existed in LLVM for Xcode 4.5 but had bugs and wasn’t exposed with NS_REQUIRES_SUPER until Xcode 5.0
  • When creating a class that is expressly purposed to be a base class that is subclassed, any method that is supposed to be overridden but needs to have the super implementation called needs to use this macro.
  • This attribute can be a large codebase win by contextualizing what methods are necessary for a base class to work. Widely adopt this attribute and your codebase will benefit.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@interface MyBaseClass : NSObject
- (void)handleStateTransition NS_REQUIRES_SUPER;
@end
// ...
@interface MyConcreteClass : MyBaseClass
@end
@implementation MyConcreteClass
- (void)handleStateTransition
{
     [super handleStateTransition]; // <-- without this line the compiler will generate a warning (great for catching bugs!)
     // do more stuff
}
@end

 

ARC __attribute__ directives
__attribute__((objc_precise_lifetime)) and NS_VALID_UNTIL_END_OF_SCOPE

Indicate that the given variable should be considered valid for the duration of its scope

  • Though this will rarely come up, it can be a big help combatting a brain scratching crash that only appears in release builds (since the optimization likely doesn’t happen in your debug build)
1
2
3
4
5
6
7
8
9
10
11
12
- (void)foo
{
    NS_VALID_UNTIL_END_OF_SCOPE MyObject *obj = [[MyObject alloc] init];
    NSValue *value = [NSValue valueWithPointer:obj];
// do stuff
    MyObject *objAgain = [value pointerValue];
    NSLog(@"%@", objAgain);
}
/* in ARC, without NS_VALID_UNTIL_END_OF_SCOPE, the compiler will optimize and after the obj pointer is used to create the NSValue the compiler will have no knowledge of the encapsulated use of the object in the NSValue. ARC will release obj and this NSLog line will crash with EXEC_BAD_ACCESS because the reference retrieved from the NSValue and stored in objAgain will now be pointing to the deallocated reference. */

__attribute__((ns_returns_retained)) and NS_RETURNS_RETAINED
Indicates to ARC that the method returns a +1 retain count.
Per Apple: only use this attribute for extraneous circumstances. Use the Objective-C naming convention of prefixing your method with alloc, new, copy, or mutableCopy to achieve the same result without an attribute.

  • ARC will follow a naming convention and this directive for how to manage the returned value’s retain count. If the implementation is non-ARC, it is up to the implementation to adhere to the rule such that when an ARC file consumes the API the contract is adhered to.
  • Honestly, you should just use the Apple recommend method prefix for methods and reserve this only for cases where you create an object with a +1 retain count with a function.
1
NSString *CreateNewStringWithFormat(NSString *format, ...)NS_FORMAT_FUNCTION(1, 2) NS_RETURNS_RETAINED;

__attribute__((ns_returns_not_retained)) and NS_RETURNS_NOT_RETAINED

Indicates to ARC that the method returns a +0 retain count. Default behavior of all methods and functions in Objective-C.
Per Apple: only use this attribute for extraneous circumstances. Use the Objective-C naming convention of NOT prefixing your method with alloc, new, copy, or mutableCopy to achieve the same result without an attribute.

  • ARC will follow a naming convention and this directive for how to manage the returned value’s retain count. If the implementation is non-ARC, it is up to the implementation to adhere to the rule such that when an ARC file consumes the API the contract is adhered to.
  • The only use for this attribute would be if you prefixed a method with alloc, new, copy, or mutableCopy but you didn’t want a +1 retain count – which is just nonsense. You should never need to use this attribute as it is implied on any method that doesn’t have a +1 keyword prefix.
1
- (NSString *)newUnretainedStringWithFormat:(NSString *)format, ... NS_FORMAT_FUNCTION(3, 4) NS_RETURNS_NOT_RETAINED;

 

__attribute__((objc_returns_inner_pointer)) and NS_RETURNS_INNER_POINTER
Indicates that the method will return a pointer that is only valid for the lifetime of the owner. This will prevent ARC from preemptively releasing an object when the internal pointer is still in use.

  • This is actually a very important attribute that few developers do a very good job of using, but really should. If a method returns a non Objective-C reference, then ARC doesn’t know that the returned value is a reference that belongs to the owning object and will go away if the owning object goes away. Without this attribute, after the final use of an object ARC will release it. This can result in a crash if the inner pointer is referenced after the last use of the object since it could have been deallocated. Ordering lines of code is not enough either, since the compiler could easily reorder the execution order as a way to optimize.
1
2
3
4
5
6
7
8
9
10
11
12
13
@interface NSMutableData : NSData
- (void *)mutableBytes NS_RETURNS_INNER_POINTER;
@end
void Foo(void)
{
     NSMutableData *buffer = [[NSMutableData alloc] initWithLength:8];
     char* cBuffer = buffer.mutableBytes;
     memcpy(cBuffer, "1234567", 8); // crash if NS_RETURNS_INNER_POINTER doesn't decorate the mutableBytes method
     printf("%sn", cBuffer);
     (void)buffer; // this will not save us from a crash if the mutableBytes method isn't decorated with an NS_RETURNS_INNER_POINTER
}

 

__attribute__((ns_consumes_self)) and NS_REPLACES_RECEIVER
Indicates that the provided method can replace the receiver with a different object.
Presumes a +0 retain count (which can be overridden with NS_RETURNS_RETAINED, but if you do that you really need to be asking yourself “what the heck am I doing?”).

  • By default, all methods prefixed with init are treated as if this attribute were decorating them.
  • ARC makes this behavior really easy to implement. non-ARC implementers of the same behavior still need the decoration but also have to pay closer attention to how they are managing memory in the implementation. (awakeAfterUsingCoder: is regular source of memory leaks in non-ARC code bases)
1
2
3
@interface NSObject (NSCoderMethods)
- (id)awakeAfterUsingCoder:(NSCoder *) NS_REPLACES_RECEIVER;
@end

 

__attribute__((objc_arc_weak_reference_unavailable)) and NS_AUTOMATED_REFCOUNT_WEAK_UNAVAILABLE
Indicates that the decorated class does not support weak referencing

  • Mac OS X Examples: NSATSTypesetter, NSColorSpace, NSFont, NSMenuView, NSParagraphStyle, NSSimpleHorizontalTypesetter, NSTextView,NSFontManager, NSFontPanel, NSImage, NSTableCellView, NSViewController, NSWindow, and NSWindowController.
  • iOS and Mac OS X Examples: NSHashTable, NSMapTable, or NSPointerArray
1
2
3
4
NS_AUTOMATED_REFCOUNT_WEAK_UNAVAILABLE
@interface NSHashTable : NSObject </*Protocols*/>
//...
@end

 

NS_AUTOMATED_REFCOUNT_UNAVAILABLE
Indicates that the decorated API is unavailable in ARC.

  • Can also use OBJC_ARC_UNAVAILABLE
1
- (oneway void)release NS_AUTOMATED_REFCOUNT_UNAVAILABLE;

More __attribute__ directives
__attribute__((objc_root_class)) and NS_ROOT_CLASS
__attribute__((constructor(…))) and __attribute__((destructor(…)))
__attribute__((format_arg(…))) and NS_FORMAT_ARGUMENT
__attribute__((nonnull(…)))
__attribute__((returns_nonnull))
__attribute__((noreturn))
__attribute__((used))
__attribute__((unused))
__attribute__((warn_unused_result))
__attribute__((error(…))) and __attribute__((warning(…)))

in, out and inout

While we’re on the topic of providing context to code we should take the briefest of moments to bring up the Objective-C keywords in, out and inout. These little keywords are used to attribute Objective-C method arguments to provide context on whether the parameter is for input, output or both. These keywords came about with distributed objects along with oneway, byref, and bycopy but, in the spirit of providing context to programmers, these keywords can bridge the gap between the consumer of an API presuming how an argument will behave and knowing how that argument will behave. Consider using inout or out the next time you return a value via an argument and consumers of your API will appreciate it.

in
Indicates that the given argument is used only for input. This is the default behavior for non-pointers and Objective-C objects.

  • Use this keyword for methods that accept a pointer to a primitive that is read but never modified. Not a common case.
1
2
3
4
5
6
7
- (void)configureWithRect:(in CGRect *rect)
{
    if (rect) {
        _configRect = *rect;
    }
    [self _innerConfigure];
}

out
Indicates that the given argument is used just for output. This is never a default behavior.

  • This keyword doesn’t make sense to apply to non pointers, which are always in arguments.
  • Use this keyword for methods that return a value via an argument but don’t read that argument.
1
2
3
4
5
6
7
- (void)configure:(out NSError **error)
{
     NSError *theError = [self _configure];
     if (error) {
        *error = theError;
     }
}

 

inout
Indicates that the given argument is used for both input and output. This is the default behavior for pointers, except for Objective-C objects (which default to in).

  • This keyword doesn’t make sense to be applied to non pointers, which are always in arguments.
  • Use this to provide context when it may not be apparent how the pointer behaves.
  • Always use this to provide context when a method has numerous pointer arguments and at least one is in or out. Basically, when there are multiple pointer arguments and they are not all inout, every pointer argument should specify its behavior.
1
2
3
4
5
6
7
8
- (void)configureRect:(inout CGRect *rect)
{
     if (rect) {
         if (CGRectIsNull(*rect)) { // where rect acts an "in" argument
             *rect = CGRectMake(_x, _y, _w, _h); // where rect acts as an "out" argument
          }
      }
}

 

__attribute__ directives as a tool
With such a valuable tool available to the C languages, any team can benefit by using these __attribute__ directives to give context in their code. At Twitter, with a very large code base and many engineers developing on it daily, every bit of context that can be provided helps in maintaining a quality code base for reuse. Adding __attribute__ directives to your toolbelt of code comments and good naming conventions will give you a robust toolset for providing indispensable context to your code base. Don’t shy away from adding __attribute__ directives to your next project. Use them, evangelize them and everyone will benefit.

__attribute__ resources
GCC __attribute__ documentation
Clang __attribute__ reference
Clang Objective-C ARC Attributes
NSHipster’s __attribute__ blog post

Apple should be more service-oriented, less hardware oriented

A week after hype surrounding Apple’s delivery of it’s latest iteration of iPhones, the iPhone 5S and it’s cheaper cousin, the iPhone 5C, it’s time to reflect on the state of Apple’s innovations.
iPhone 5C

 

 

 

 

 

 

 
No one could argue that there weren’t really any surprises in this year’s announcements, the internet has been so accurate in guessing what this year’s features will include that the dead-accuracy is probably the only real surprise in 2013. But what can we expect? Innovation isn’t a yearly cycle, and investors are putting too much pressure on companies like Apple to create something radical each iteration.

We all know what shambles MobileMe was, and even though Apple promised iCloud would be a massive improvement, it did iron out some of the annoyances of MobileMe, but still rather primitive and buggy, compared to Google Drive and other services.  Apple is also focusing on it’s OSX hardware and software, so with so many fingers in so many pies, how can it make everyone happy all of the time?

But Android manages innovation

KitKatYes, Google’s ecosystem, whilst started way behind Apple when the iPhone first came out, it was working at a much faster velocity and acceleration, because of smart delegation or concentration of research. It left the hardware R&D to companies like HTC and Samsung, and others, it focused on improving it’s services and operating system over time. Granted, it was only until last year that we began to saw the project come to fruition, with Android 4.2 and 4.3 basically on par with Apple’s iOS, in terms of smoothness. Even if people disagree with me here, if not this year, then next year.

OK so the hardware out there from Samsung and HTC weren’t that great a few years ago but this year it has gotten really amazing, with HTC showcasing the One and it’s premium built, with the S4 sporting a large screen, amazing specs and so forth.

 

Google can afford to concentrate on software by letting other vendors deal with hardware. The pace of operating system innovation will level off for both companies, but Google is still pressing ahead with it’s cloud strategy which is far more mature than Apple’s. Take a look at how much better GMail is, Google Maps, Google Calendar and Google+/Hangouts, and with each iteration bringing tighter integration between the services. Apple is spreading itself too thin, and knowing the structure Steve Jobs had in place, each unit or team is quite small.

So Apple, it’s time to start looking at the cloud

I personally thing it’s about time Apple looks into a massive overhaul and drive on the services side. Perhaps it won’t ever beat Google in building a search engine or email system, which is why I think Apple needs swallow it’s pride and collaborate with Google, or Facebook (pick an already existing ecosystem), integrate it’s services better, and release more APIs for developers to work with. It’s about time FaceTime is given public access, and many similar things, like Reminders needs to be more open.

Allow Developers to implement third party keyboards in iOS, there is so much that can be opened up, without being as vulnerable as Android. Look at building an Apple equivalent to Google Apps. In fact, get rid of iTunes and go browser based, like Google has. We don’t need a physical desktop app to act as conduit anymore.

We don’t need an iPhone every year, but at least put out a variety of sizes, and everyone is happy. Just look at the iPads, we have two sizes and so that more than satisfies the market, do that with the iPhone and we are set. I firmly believe that hardware is becoming more and more irrelevant, with services and software taking a more prominent role. Look at YouTube, where you can now edit your videos on the cloud. I wouldn’t go as far as to get a Chromebook just yet, but it doesn’t take a rocket scientist to realise what the trend is.