A look at how Swift structs lay out memory and what it inherits from C.

Date: October 30, 2023

Let's dive into a fascinating topic today - Swift structs and their memory dynamics. In computer programming, particularly in languages like C and C++, "struct packing" refers to the arrangement of data within a struct or structure in memory. The term is often used in the context of memory layout and optimization, especially when dealing with low-level programming and data structures. Swift's struct packing and memory handling inherit some wisdom from the past, particularly from the world of C programming.

The C Struct

Structs are used to group related data together, and how the elements within a struct are stored in memory can have a significant impact on program performance and memory usage. By default, many compilers will try to align struct members in memory to improve data access performance, which can lead to "padding" or unused bytes between members to meet alignment requirements. For example, consider the following struct in C:

c struct Example { char a; // 1 byte int b; // 4 bytes (assuming a typical 32-bit system) double c; // 8 bytes };

In this example, the **`struct Example`** contains a **`char`**, an **`int`**, and a **`double`**. The size of this struct, in total, might be larger than the sum of the sizes of its individual members due to padding introduced for alignment. On a typical 32-bit system, you might find that there is 3 bytes of padding added after the **`char`** member (**`a`**) to ensure that the **`int`** member (**`b`**) is properly aligned to a 4-byte boundary. There may also be additional padding at the end of the struct to ensure that the **`double`** member (**`c`**) is correctly aligned to an 8-byte boundary.

Now, if you were to change the order of the members like this:

```c
struct Example {
    double c;  // 8 bytes
    int b;     // 4 bytes
    char a;    // 1 byte
};

The memory layout may change, and the amount of padding introduced may differ. In this case, there might be no padding between the double and int members, but there could still be padding at the end to align the double. The total memory size of the struct could be different due to this change in padding.

So, changing the order of variables in a struct can impact the memory size due to differences in alignment requirements. The exact padding added by the compiler can depend on the specific architecture, compiler settings, and data types used in the struct. To minimize padding and control memory layout, you can use compiler-specific directives or attributes (such as attribute((packed)) in GCC) or reorder the struct members strategically based on the alignment requirements of your target system. However, optimizing for memory size may come at the cost of performance, as unaligned access to data can be slower on some architectures.

Intro to Swift Structs

Before we unravel the magic of struct packing, let's have a quick refresher on what a Swift struct is all about. Imagine a struct as a handy way to bundle related data into a neat package. Each piece of data inside a struct is called a member. Here's a basic example:

swift struct Point { var x: Double var y: Double }

In this example, we've got a struct named `Point` with two `Double` members, `x` and `y`. It's like having a mini-coordinate system in a single entity.

## The Legacy of Memory Layout

Swift doesn't reinvent the wheel when it comes to memory layout and alignment. It takes a page from the C playbook. Every data type has an alignment requirement, specifying how it should line up in memory. For example, `double` usually needs an 8-byte alignment, while `int` might need 4 bytes.

Swift's goal is to make sure each struct member lines up properly. If it has to, it throws in some padding bytes to meet alignment requirements. Padding might sound like a bit of a buzzkill, but it's essential to ensure efficient memory access. I hear that you don't want to deal with the sluggishness of unaligned memory operations.

## Swift's Struct Packing Saga, Inspired by C

Swift aims for optimal memory usage and speedy access, and it carries over some concepts from C. In Swift, the memory layout and alignment of structs are managed by the Swift compiler, and it aims to provide a more predictable and consistent behavior compared to some other programming languages like C and C++. However, Swift structs can still be affected by memory alignment and padding, but the compiler makes efforts to minimize these issues.

Swift automatically aligns struct members according to their types and alignment requirements, just like in other languages. This alignment is designed to optimize access times and ensure memory safety. Swift also provides control over memory layout in the form of compiler attributes and annotations, such as **`@alignment`** and **`@packed`**, which can be used to control alignment and packing if necessary. However, there's room for your input to fine-tune struct packing:

### 1. It's All About Member Order

Just like in C, the order of members in a struct can shake things up in the memory layout. Swift tends to put the larger members upfront to minimize padding. It's like playing a game of Tetris with your data. Take this struct, for instance:

```swift
struct Employee {
    var salary: Double  // 8 bytes
    var employeeID: Int // 4 bytes
}

In this struct, salary takes the lead to minimize padding, just like how C would do it.

2. Go for Slimmer Data Types

If memory is important opt for smaller data types, such as Int32 instead of Int, to keep the memory footprint lean. Smaller data types typically come with smaller alignment requirements and less padding. Here's an example:

swift struct SensorData { var value: Int32 // 4 bytes var timestamp: Double // 8 bytes }

### 3. The `@Packed` Attribute

Swift throws a wildcard into the mix with the `@packed` attribute. Apply it to a struct if you want to minimize padding, akin to C's packed attribute. But tread carefully, as it might impact performance on certain systems:

```swift
struct MyStruct {
    var a: Int32
    var b: Double
} @packed

4. Beware of Reference Types

Stay cautious with reference types like classes within a struct. They bring along some extra memory overhead, another lesson inherited from C. Remember, structs are all about values, so adding reference types can bulk up their size.

Determining the Size of Swift Structs

In Swift, you can determine the size of a struct or any data type using the MemoryLayout struct and its size property. MemoryLayout is a generic struct that provides information about the memory layout and size of Swift types. Here's how you can use it to find the size of a struct:

swift struct MyStruct { var a: Int var b: Double }

let sizeOfMyStruct = MemoryLayout<MyStruct>.size print("Size of MyStruct: \(sizeOfMyStruct) bytes")

In the code above, we define a struct `MyStruct` with two members, an `Int` and a `Double`. We then use `MemoryLayout<MyStruct>.size` to obtain the size of `MyStruct` in bytes and print it to the console.

This will give you the size of the struct in bytes as it would be laid out in memory. Keep in mind that the actual size of a struct can be affected by factors like padding and alignment, which are determined by the Swift compiler to optimize memory access and performance. The `MemoryLayout` struct provides information based on the compiler's decisions.

## The Delicate Balance

Now, here's the catch: optimizing struct packing is like walking a tightrope. You want a sleek memory footprint, but you also crave top-notch performance. Overdoing it with packing and alignment tweaks can lead to performance hiccups, especially on architectures that demand strict alignment.

Always keep an eye on memory usage and performance by profiling your application. It's the only way to ensure your optimizations hit the bullseye without introducing unexpected side effects.

In the grand scheme of things, Swift's memory layout and struct packing principles have a rich lineage from C. This inheritance ensures that Swift strikes a harmonious balance between memory efficiency and performance, benefiting from the wisdom and experience of its predecessor.

So, fellow Swift enthusiasts, go forth and craft those memory-efficient structs while keeping your code clean and snappy. Swift is the future, and it brings along a bit of the past to make it even better.

Why Swift type inference can cost performance and what to watch.

In the world of programming languages, Swift has emerged as a dynamic and versatile option. Its type inference feature, while powerful, isn't without its quirks. Like any technological innovation, Swift's type inference has its own set of performance considerations that developers should be aware of. In this essay, we'll delve into the fascinating realm of Swift's type inference and explore how it can sometimes impose performance penalties.

The Duality of Swift's Type Inference

Swift's type inference is a double-edged sword. It's the magic that makes your code cleaner by inferring data types without requiring explicit annotations. While this enhances readability and maintainability, it can also have unintended consequences on compile time performance. Let's uncover why.

Code Complexity

Imagine Swift as your trusted assistant. The more complex the tasks you assign, the more time it takes to complete them. In the programming realm, this translates to the complexity of your code. Deeply nested or intricate expressions can lead to prolonged compilation times as the compiler diligently deciphers types.

The Generics Conundrum

Generics, a powerful feature in Swift, can be a culprit in performance slowdowns. Swift's type inference must traverse complex generic hierarchies, inferring types for generic functions and types, which can be computationally intensive.

Module Size and Codebase

The size of your Swift module and codebase can also influence compilation performance. Large modules with numerous interdependencies can amplify the impact of type inference on build times.

Swift Version Matters

As Swift evolves, so does its compiler's performance. Newer Swift versions often bring optimizations and improvements in type inference. Keeping your Swift environment up-to-date can positively impact compilation speed.

Mitigating the Impact

Now that we've explored the potential performance penalties of Swift's type inference, how can we mitigate them?

1. Mindful Use of Type Annotations: Although Swift shines with type inference, judiciously using explicit type annotations can sometimes provide clarity and speed up compilation. 2. Modularization: Break down your code into manageable, modular components. Smaller scopes reduce the workload on type inference, potentially improving compilation times. 3. Profile and Optimize: Profiling your code's compilation performance using tools like time or Xcode's build time profiler can identify bottlenecks. Optimize your code based on these insights. 4. Dependency Management: Keep dependencies in check. Excessive or unnecessary dependencies can exacerbate compilation complexities. 5. Compiler Flags: Experiment with compiler flags like O (optimization) and whole-module-optimization to enhance compilation speed. Note that aggressive optimization can sometimes extend compilation times.

Swift's type inference is a boon for developers, making code cleaner and more expressive. However, it's vital to recognize that, like any powerful tool, it comes with its own performance considerations. By understanding the potential performance penalties and implementing the recommended best practices, you can strike a balance between code elegance and efficient compilation. In the dynamic world of Swift, optimization is the key to keeping your development process smooth and swift.

Switching to Explicit Types

Swift, Apple's powerful and versatile programming language, is known for its strong type inference system, which allows developers to write concise and expressive code. However, there are situations where specifying explicit types can be beneficial, such as improving code readability and enhancing collaboration among team members. In this essay, we'll explore how a simple regular expression can assist developers in transitioning from Swift's type inference to explicit types.

The Challenge

Swift's type inference is excellent at deducing variable types based on their initial values. For example, if you write:

swift let name = "John"

Swift knows that `name` is of type `String` because it's initialized with a string literal. While this is convenient, it may lead to code that lacks clarity when dealing with complex or unfamiliar codebases.

Explicit types can help in understanding the intent behind a piece of code, especially when variable names are not descriptive enough. But manually specifying types for every variable declaration can be time-consuming and prone to errors.

**The Solution: Regular Expressions**

Regular expressions (regex) are powerful tools for pattern matching and text manipulation. They allow you to find specific patterns within text, and in our case, we can use them to identify Swift variable declarations that lack explicit types. Let's take a closer look at the regex pattern we'll use:

(var|let) ([a-zA-Z]+) = ([A-Z][a-zA-Z0-9]*)\(

Breaking Down the Regex Pattern

1. `(var|let)`: This part matches either "var" or "let" and captures it as a group. In Swift, all variable declarations start with either "var" or "let."
2. `([a-zA-Z]+)`: This captures the variable name. It matches one or more alphabetic characters (uppercase or lowercase). Variable names in Swift usually follow this pattern.
3. `= ([A-Z][a-zA-Z0-9]*)`: This part matches the equal sign followed by a type. It captures the type as a group. Here, we assume that explicit types start with an uppercase letter, followed by a combination of uppercase letters, lowercase letters, and digits.
4. `\\(`: The regex pattern ends by matching an opening parenthesis. This helps ensure that we are looking at variable declarations with initializers.

Using the Regex Pattern

To leverage this regex pattern effectively, you can incorporate it into your code editor or use a specialized tool for regex-based find and replace. For instance, if you're using Xcode, you can enable regular expressions in the Find and Replace feature and use this pattern to locate variable declarations without explicit types.

Here's a step-by-step guide on how to do it in Xcode:

1. Open your Xcode project.
2. Press `Cmd + F` to open the Find panel.
3. In the Find panel, make sure "Regular Expression" is selected as the search option.
4. In the "Find" field, enter the regex pattern:

(var|let) ([a-zA-Z]+) = ([A-Z][a-zA-Z0-9]*)\(

5. Press "Find" to locate the matching variable declarations in your code.
6. Review the results to identify variable declarations that lack explicit types.
7. Consider adding explicit types to these declarations based on your understanding of the code's logic and requirements.
8. If needed, you can use "Replace" to update the variable declarations with explicit types.

$1 $2: $3.init(

Benefits of Using the Regex Pattern

Using this regex pattern, you can quickly identify variable declarations that might benefit from explicit type annotations. Explicit types can make your code more understandable and maintainable, especially in larger codebases or when collaborating with a team.

By taking advantage of Swift's strong type system, you can catch potential issues at compile time and improve code documentation. Additionally, explicit types can help new developers understand your code more easily, making onboarding smoother.

Conclusion

While Swift's type inference is a powerful feature, there are scenarios where specifying explicit types can enhance code readability and maintainability. By using a simple regular expression pattern, you can identify variable declarations in your codebase that might benefit from explicit types. This approach streamlines the transition from Swift's type inference to explicit types, resulting in cleaner and more understandable code.

Setting up rismay.me with Fruition and reflecting on the return to writing.

Date: June 1, 2020 12:00 AM (PDT)

A big OMG moment this week has been setting up cloudflare workers with fruitionsite.com. This feels right for the rismay.me! It's my personal internet space and process of me writing to publishing should be as quick as possible. However, it is crazy how similar it is to postach.io, a writing site I started in 2013! The web works in both fast and slow ways. The feeling of deja-vu is here and I'm feeling old. In fact, the initial content for my site will come from those original posts.

After another week of exploration, the notion community continues to impress. Notion has this uncanny ability to be really simple to setup but hard to master. But not really hard, just sufficiently hard. In fact this is a common gaming pattern! Every level of understanding the product creates a sense of accomplishment. Small "Aha!" moments littered throughout the way. They even out right use gamification by giving users credits in order to get to know their product.

First impressions of Notion and its second-brain potential.

And just like that, I'm off and running. I can't remember the last time I had an experience like this. This seems like an iPhone moment. The entire Notion environment and related ecosystem is very easy to use. I was able to import more than 11 years of memories in less than a couple of hours. I was able to start processing those memories in more dynamic ways in less than 12 hrs. The key ingredients of the second brain are here.

However, the concept behind Notion is one that I am familiar with. It looks and feels like a far off concept I once envisioned is now here. "Workstreaming" is a corporate level speak for what is more commonly known as Kanban. Coming from JPMorgan, I thought it would be cool if everyone had this. That's why my original concepts were called "wrkstrm".

Finally, I must complain. I don't think Notion would have gotten here without React Native. Yet as a native developer, I don't like it. Every now and then I see flickering, generic transitions or some other known side effect of essentially running a web browser. I hate that. Then again, have we reached the uncanny valley of web development? Will we be there in 2 years, 5 years? At that point will native have advantages?

Using Notion raises as many questions as it answers.

Starting a switch to a more capable all-in-one productivity tool.

Today is the first day of my switch to a more capable all-in-one productivity tool! I feel like I have tried so many things yet so few have stuck. I hope this one does!

First, I tried Evernote. It did a lot for me. However, it got convoluted. The first hint that this solution was doomed was the bad reminders functionality. The second was the never updated penultimate support. To this day, the drawing just does not feel natural.

Then, I tried Atom. It was shiny and new. However, when I think about the reason of why I started it (to use git as a task database), that never paid off. Mainly, the goal was learning git while using it as my note taking system.

Then, I tried the imdone atom extension and mac app. It has worked for me for the better part of 4 years! It was great for the kanban view but I was trying to hack a productivity system out of text. I did this semi consistently, but the friction of keeping it up to date has been hard. You have to sync every computer you use manually via push and pull. You need Atom. You Need the Mac app. Resolve conflicts. Add metadata by hand. The system was falling apart at the seams...

Hopefully, Notion does all of this. From what I heard, it enables the second brain method. It also allows for you to get all areas of your life together into one place. This was the goal behind wrkstrm.me, a concept I had about 9 years ago. I never fleshed it out because I wanted to get professional iOS experience instead, but the concept has always been at the back of my mind.

I wish the Notion team the best of luck.

A logging approach that improves multithreaded debugging beyond NSLog.

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

— Brian W. Kernighan

When I first started coding Objective-C, I relied on NSLog to understand how to code was flowing. I would print out statements like this:

NSLog(@"WSPL:overlaysWithWSActivity:MID01 count: withActivity: Looping through activity of size %i", newActivity.coordinates.count);

Looking back this is obviously not the way to go about things. “WSPL” was a way for me to get which file was logging this command. I then manually printed out the method (“overlaysWithWSActivity:count:withActivity”). The “MID01” token was a way of identifying what line I was actually at. Finally, I put in the actual bit of information that I wanted “Looping through moments.”

Luckily, I stumbled upon CocoaLumberjack. The library comes with several built in loggers which you can customize to your liking, but did not quite give me the level of detail that I needed. The shortcomings came particularly apparent while working on multi-threaded code. Although, I was getting the info I needed I did not know from what thread or queue the work was being performed.

My solution to all of these problems came in the form of WSMLogger. Now I get log statements that I code like this:

NSLog(@“Nice”);

But output that looks like this:

01:03.147-main[AppDelegate |-[AppDelegate application:didFinishLaunc] Nice!

Why is this better? When dealing with multi-threaded code, milliseconds matter. So I opted for just minutes, seconds and nanoseconds as the timestamp. The thread, the file name, the object, and method are then automatically printed. And finally, I can control the individual length of characters each component gets per log statement. So how do you use this awesome logging.

You should, learn how to use cocoa pods. Add “pod ‘WSMLogger’” to your Podfile. For ease of use, add <WSMLogger/WSMLogger.h> to your .pch file. From now on, all NSLog statements will be replaced with a C Macro that will call on DDLog. Add to your AppDelegate file a class load method with the settings for that you want for the WSMLogger. For example, I use:

objc #pragma mark - Custom Logging at Startup

+ (void)load {

WSMLogger *logger = WSMLogger.sharedInstance;

[DDLog addLogger:logger];

// Customize the WSLogger

logger.formatStyle = kWSMLogFormatStyleQueue;

logger[kWSMLogFormatKeyFile] = @16;

logger[kWSMLogFormatKeyFunction] = @40;

}

What does that text snippet do? Firstly, it creates the WSMLogger, and registers it with CocoaLumberjack. Second, it sets the style to use (I have created different styles in WSMLogger). Finally, it sets the number of characters to use for the File and Method name.

That’s it! All your pre-existing NSLog statements will automatically output with the new format you have customized.

Choosing between portability and performance, I compare the 2013 13-inch rMBP and the discounted 2012 15-inch rMBP.

I previously posted that I returned my Late 2013 13” rMBP after I encountered the dreaded unresponsive keyboard glitch. This is a bit disingenuous because the ultimate reason I returned the notebook was to purchase a more powerful version of the same laptop after the Keyboard/Trackpad problems were confirmed to be software issues. However, when I went to look at my buying options, I discover that Apple was offering the original 2012 15” rMBP for $1600. That’s $500 off for a laptop that comes with a 1 year warranty. This post is simply to help those wondering: Should you pay $100 more for a refurbished original 15” Retina Macbook Pro vs a new Late 2013 13” MacBook Pro Retina?

If battery life and portability are important to you, then you should undoubtedly go with a new late 2013” rMBP. The MacBook Air should only be considered if you cannot spend the extra money. The combination of new technology, portability and price reduction make the new 13” rMBP an especially formidable machine. Since it’s less than 1/2 a pound heavier than the MBA but slightly smaller in proportions, I can’t see anyone making an argument that the MBA is more portable. Personally, I wanted to buy the 256 GB version with an upgraded processor. With an education discount, which is rather easy to get, the price of the laptop comes to $1490. Without the discount the price reaches $1600. Why the upgraded processor? Because my computer stuttered when I performed the initial Evernote library sync pretty badly. I didn’t get a chance to test any games with the new system, but I don’t think I would have liked the results.

Like, I said before I returned my 13” rMBP, it’s an amazing computer. The SSD reads at an amazing 750 MB/s. That’s a huge advantage for someone like me who was coming from a Late 2011 15” MBP whose HHD would top out at 120 MB/s. Also, for the 13” rMBP is 227 ppi vs the screen resolution of 220 ppi of the 15” rMBP. Although the effective desktop space is lower than the 15” version, the resolution was just right and for some odd reason very noticeable when I tried out the 15". Finally, the battery life is amazing. I was able to fly from Houston to NY and only use about 30% of my battery life. I’m used to my laptop running out of juice before I land. Using the 13” rMBP felt like what I would imagine moving from a Nissan Leaf to a Tesla Model S would feel life. No more range anxiety! If I would care deeply about portability and battery life, I would definitely go for a new 2013 Late rMBP.

However, I care about raw performance. Here are some geekBench 3 stats regarding the CPU performance. While the 13” rMBP scored a 5600, the 2012 15” rMBP scored a 9500 - about a 70% increase in performance! That doesn’t even take into account the dedicated graphics card which the 15” offers. I don’t care how advanced your “integrated graphics” are. A 1 GB DDR5 graphics card will run circles around you. I heard it’s actually better to hook up a second 1080p display to play video games on this machine and I definitely plan on getting Borderlands 2 to test that out.

I don’t mind carrying a charger around. Besides, with the Mavericks battery life improvements the old 15” rMBP can last a little bit longer between charges. The only draw back this presents is how much heat the dedicated graphics card produces. I don’t understand Apple’s obsession with lowering the noise levels of their fans while at the same time increasing the temperature of their chassis. It’s mid fall in NY right now and I actually appreciate how hot this laptop runs, but I can see how this could be a serious problem when I’m vacationing mid summer in Houston. Another complaint that that I have is the physical size of the 15” rMBP. Although, it’s smaller that the non-retina version, It feels denser. The 15” rMBP feels like an iPhone 4S while the 13” rMBP feels like an iPhone 5.

Finally, the price of upgrading my technology ecosystem to the level which the late 2013 13” rMBP offers is just too much for me. First, I would have to upgrade my router. A good AC router goes for around $125. Then I would have to update my Thunderbolt drives to take advantage of the new Thunderbolt 2. I spent a good chunk of money on the WD 4TB Thunderbolt chassis which allows you to replace the HDD when they go bad. All I really need is USB 3 which the late 2012 15” rMBP offers. Finally, although the SSD speeds of the new 13” are amazing, the original 15” rMBP offers 450 MB/s speeds. Those are amazing speeds (However, I do hear that the new 15” rMBP offers over 1 GB/s speeds, so I guess everything is relative).

I hope this helps.

Acting taught me empathy and scene work that map directly to software development.

This might sound weird, but my experience acting is the most relevant study/project/work I've done to prepare me as a developer.

I came to this realization after I applied for a

Flatiron School Fellowship

position to gain more Ruby on Rails experience. Until now, wrkstrm has a completely native Objective C codebase. There is no intermediary PhoneGap or Xamarin type of framework which uses Javascript or C# in my projects. I chose not to use those frameworks for aesthetic and moral reasons rather than the simple fact they help ship apps. After all, I am not a paid developer. When coding, I optimize fun or enjoyment rather that practically. During the application process, one question struck me as odd:

The ability to think in a structured or quantitative way to solve complex problems is an important element of being a successful developer. Can you tell us anything that demonstrates your abilities in that realm? (feel free to include anything from standardized test scores, previous areas of study, or relevant work experience)

I submitted a response which elaborated on my experience on the Student Managed Investment Fund at Bucknell University. However, at first, I wrote out a completely different response which I would like to share in elongated form.

During my senior year in high school, I learned how to act in 3 months. At the end of my 3rd year in high school, a friend convinced me to be part of a small play - 15 minutes and only 1 scene. After coming back from summer break, the head of the theatre department persuaded me to audition for a small part in an ambitious project he was concocting. The play would be about 1.5 hours long and only feature 5 actors. Although one actor would be on stage for the entirety of the show, I was auditioning for one of the male supporting roles. To everyone's surprise, I was cast to the lead role. To this day, I don't think I have had a tougher 3 months in my life. I had to memorize 25 scenes, 5 different roles and all of the acting theory from scratch. Although this might not seem like a technical or quantitative challenge, I should probably note that I was concurrently enrolled in 3 different Advanced Placement courses: Calculus, Physics and Computer Science. As unlikely as this sounds, there are many parallels between acting and programming.

First off, acting taught me to "respect the script," meaning don't deviate from the words on the page or change the playwrights intent. Aside from programming, I have not worked on a project which required as much attention to words and syntax. As Jeff Atwood recently said, "strip away the images and gradients and vectors from even the fanciest web page, and you'll find that the web is mostly words." At the most obvious level, punctuation and even inflection are paramount on the stage. While programming, a small punctuation error will not let the program compile. On a deeper level, I have found that using different frameworks or languages require you to have a deep understanding of recurring patterns and the developers intent (what problems was he/she trying to solve?). I actually got into a huge argument about this during TechCrunch Disrupt NY 2013 with a couple of the main contributors to Ember.js. It turns out that one of the main commiters is a huge iOS junkie while the other didn't understand the more peculiar parts of Objective C. I argued that native development was better because it allowed you to take advantage of patterns that were either not available or clumsily implemented in web languages. In response, what I got was a demo of how a table view controller that was running at almost native speeds using a UIWebView - drop shadows, rotation switching and all. I just think this misses the point. If you are not coding for iOS in native Objective C, you are missing something. You are creating apps but you are missing a huge philosophical chuck of what makes iOS great. In a play, you can ad lib or change a line to say the same thing, but not mean the same thing. The playwright thought about why he chose that verb, adjective or punctuation mark in relation to dynamics of the the entire play. In that sense, when I code for iOS I "respect the script." I don't go around inventing my own patterns or use a different language.

Second, acting taught me to tackle huge problems ("memorize this script") by breaking them down into small actions. Some directors require you to be very academic about the script and request "Beat Sheets." For example, in scene 5 line 4: What am I saying? What is my character thinking? Where am I standing? The point of a beat sheet is to document the intention behind every line. Sound familiar? It's the equivalent of composing a method's documentation. Every line must be analyzed in perspective of every scene. Every scene must be a single arc within the grand story of the play. Eventually any play can be summarized into one sentence. This one sentence must be taken into account while performing every line. To me, this is the equivalent of an App Definition Statement. More over, when I first started programming I thought that being able to code huge classes and methods was a badge of honor. Just like how my first day at rehearsal, I was also very ambiguous about how I delivered my lines in a given scene. I have since learned that it is better to code small single purpose methods and to break up huge classes into smaller ones. How should methods be implemented? How should these classes be broken up? It depends on the goal of the program. Just like an actor can put his spin on a certain role, a developer can put a certain personal mark on his code. The only requirement is that you be consistent, deliberate and keep perspective of the project as a whole.

I hope this gives new meaning to the term, "Method Acting."

Apple has refined Core Location to improve battery life and location accuracy over time.

There seems to be a lot of interest in the new iOS 7 location APIs - CoreLocation. Here is a great hacker news discussion about it. I want to provide a little more "context" to this discussion.

As an aside checkout:

- Jer Thorp's talk from a TedX talk a couple of years back regarding location history. - William Edward's work on grabbing location data from your iPhone backups.

My Background:

Here is a quick 1.5 minute demo of wrkstrm I made for the AngelHack 2012 summer finals.

iOS 2:

Apple introduces CoreLocation with a minimal amount of features. Programmers can ask to be updated about GPS coordinates only when their Apps are in the foreground.

iOS 5:

Apple adds two huge additions which introduced significant location monitoring and geo fencing. This information was already being logged by the iPhone (there was a huge scare about this in 2011). All Apple did was give developers access to this data without having to hack (check out William Edward's demo and Jer Thorp's OpenPaths).

Another aside: These two APIs are what prompted me to learn how to code. I was seriously disappointed when I found out that Apple was "cheating" the implementation of these APIs. The resolution to these APIs is horrible - something like football fields of disparity in inner cities. This is what started my journey into finding a more accurate way to geo fence and track locations.

iOS 6:

For this release Apple worked closely with the MapKit team to improve GPS accuracy. The best example of this is how the CoreLocation team used the new MapKit vector graphics to clip GPS coordinates to streets. Again, Apple didn't invent a new technology to improve GPS accuracy, it leverage a new user interface innovation. To implement this Apple released a activity type (driving, walking, etc) API which alerted CoreLocation as to when it would be appropriate to clip coordinates.

iOS 7:

These screenshots use a different approach to generate. This information is NEW and gathering it was made possible by two sensor driven user interface innovations which seem totally irrelevant. First, in iOS 6 Apple started running the accelerometer all day with it's "raise to speak to Siri" feature - (simply put the phone to your ear to activate Siri). Now with iOS 7, Apple has introduced a "constant on" gyroscope, with the introduction of the Parallax effect. Apple can measure "stay" events when the iPhone is not moving without resorting to expensive / inaccurate geo fencing. Why am I so sure that this is what Apple is doing? Apple was originally planning to go even further by providing step count data (similar to the Galaxy S4's S Health data) to developers. This is only possible by running the aforementioned sensors and using signal processing. This was shown in the new iOS 7 technologies during the keynote and even in the iOS 7 beta 1 documentation, but all mentions were abruptly removed with beta 2 and beyond. Look for this in iOS 7.1 or iOS 8.

Finally, with iOS 7, Apple went one step further. With iOS 6, Apple used to provide GPS applications real time updates. Now there is a new API that allows deferred GPS notifications so that Apple can shut down your app and give you notifications "opportunistically" (i.e. when a user turns on the lock screen). Apple claims to provide a 40% improvement in battery life using this new method. If so, this technology is a game changer for always on location trackers.

Why I chose postach.io after weighing writing options and wanting a low-friction workflow.

Should I host it on an EC2 micro instance and a ton of hacks to get thousands of hits per second?

I have been meaning to start a writing site containing my thoughts on technology - particularly the thought process behind the wrkstrm concept. However, I was really stumped when it came to finding the correct platform. There are so many options to chose from! For me, it was a classic "Paradox of Choice" problem. Writing options range from the complex:

To the simple:

How about just starting a tumblr?

or the techie:

A Jekyll site from my GitHub account?

I knew that I wanted my site to center around a tool I use almost everyday. Both github and EC2 met that criteria. However, these tools were just not user friendly.

Then came postach.io. Now, I can write with minimal friction.

“Friction" is what this site is going to be about. Technology should get out of our way so that we can focus on what matters to us. Products like twitter and Moves are great "minimal friction" environments. However, in the Quantified Self movement products like Moves and Evernote are exceptions to the rule. Generally the thinking behind each product is so new that most of the effort is simply spent on turning a new idea into an actual "thing."

This is where concepts like wrkstrm step in. I started conceptualizing wrkstrm back in August 2011 as an evernote while I was stuck on the subway with no internet access. Originally, I thought wrkstrm would be a tool to learn about people's prior experiences. However, the technology to passively capture those experiences really didn't exist at the time. Back in August 2011 the world was in a very different place. The Facebook Timeline did not exist. GPS tracking was just being used to monitor workouts. Uber was just getting started. Geo fencing had not yet entered the vernacular.

I think that the quantified self movement needs to embrace passive monitoring technologies in order to truly become mainstream. Without automating the monotony of capturing life's seemingly irrelevant moments the quantified self movement simply won't get past the "data dessert." However, wrkstrm wants to go beyond that and turn this data into art in the same way that Jer Thorp and Nicholas Felton are demonstrating is possible.

Today, the competition is very different. Companies like protogeo have essentially nailed the original wrkstrm experience. It seems like there are at least 3 teams at each hackathon pitching passive location monitoring. It is time to move on and remove friction from another aspect of life.

Stay tuned.