The New York Times has written a great dive into mobile apps that harvest data off your device, such as location data. Many of these companies feel entitled to harvest and store your data for things like location when you give consent for location access, and are in the business of selling that data to advertisers.

The book ‘1984,’ we’re kind of living it in a lot of ways.

Bill Kakis, a managing partner at Tell All

I’ve been removing a lot of the native apps I’ve relied on recently in favor of mobile web apps. I won’t let Facebook run code natively on any device I own, precisely because I know they go out of their way to capture every scrap of data they can. Running Instagram in a mobile web browser provides a much stronger sandbox, limiting the amount of data they can steal dramatically.

Apple and Google have largely destroyed any real marketplace for paid apps that don’t need to rely on selling data, and app review mechanisms have been unwilling or unable to protect customers from it. They deserve a huge share of blame for the status quo being what it is.

Link

Separating Apple Watch from iPhone as a Public Health Good


At their September event, Apple spoke of their annual upgrades to their iPhone and Apple Watch lines. While the iPhone update was mostly limited to the processor and camera, the Apple Watch had some more significant improvements, notably including the capability to capture an electrocardiogram, atril fibrillation detection, fall detection, and an emergency SOS feature.

While the original pitch for the Apple Watch included health features, it was more concerned with being a workout accessory and general activity tracker. Over the years, it has grown more sophisticated at being not just an accessory, but a true guardian of the wearer’s health. Features like ResearchKit are making it possible for medical research to be conducted on people on a daily basis. It’s clear Apple is going to continue moving the Apple Watch in this direction.

This has potential to be transformative to public health, but there’s a problem: this device is limited to people who have iPhones, which makes up about 2 in 5 US phones and 1 in 5 phones worldwide. That means these features are not available to the vast majority of smartphone users, a market that is currently starved for a comparable product. And while there are finally some signs of life for an alternate smartwatch platform, Apple’s actively working with the FDA on some of their features; they’re simply better positioned to have accurate results.

When the iPhone launched, it was tethered to a computer running iTunes, but with its fifth release, the iPhone went PC-free and became fully self-sufficient. While it’s unlikely that the Apple Watch could ever be completely run without a connection to some other device, surely there will be many features that aren’t dependent on an iPhone. The health care features alone would be transformative for many people; there are absolutely people who would buy an Apple Watch just to have a modern health guardian device. Are they obligated to make the Watch work without the iPhone? Of course not. But it would dramatically expand the market for the device, and provide a marked improvement to the health and lives of people who can’t get one today.

Fortnite Skipping the Google Play Store


This is a real power play. Epic Games is planning to push Fortnite outside of the Google Play Store by asking users to install an APK file. This will help them run around the exorbitant 30% fee that Apple instituted and Google adopted for their app stores. This isn’t the first alternative app platform to appear on Android; companies like Baidu, Tencent, Itch.io, the open source F-Droid, and even Amazon have their own stores. But it is probably the first that will get major mainstream attention (and installs) in the west. Fortnite is big enough; this will probably work.

Read More

The just-launched LG V30 has finally arrived! This new flagship Android phone from LG is gorgeous and packed with features. In this video, we’ll take it out of the box, show everything included, and get it booted up to the first launch. Full review of the LG V30 to follow, so make sure to subscribe!

So yeah, Apple wants to remove the headphone port from the iPhone, apparently. Nilay Patel wrote a rant article on The Verge describing how removing the headphone port would be “user-hostile and stupid” (like, it’s in the title of the article). He makes a compelling, if incomplete, case for why it hurts you for Apple to force this change, citing the potential for a return of music DRM, need for additional pricey adapters, major compatibility issues, and the fact that nobody really wants this.

Nilay’s article is written under the argument that it would be “user-hostile” to remove the headphone port. I’m going to define this as acting against the user’s wishes, or being designed without the user in mind. It seems pretty reasonable that a user would not want hardware compatibility issues, DRM-encumbered music, or significantly more expensive headphones. And users already have lots of devices compatible with the 3.5mm headphone port. Therefore, to remove the port in a way that is not user-hostile and stupid, Apple would have to provide more value and benefit than they are taking away, on top of whatever new features they provide.

Following it up, John Gruber writes a rebuttal comparing this transition to Apple’s removal of floppy drives in the late 90s by writing about how this will be a positive for Apple. A rebuttal should address the core argument made, and John’s rebuttal completely fails to do that.

Read More

When I released the first version of Ohai a few months ago, it had a simple goal – to have a simple, beautiful place to keep track of memories. As with all first versions, it was limited; you could only capture location-based check ins with a comment and a photo. And as it was released shortly after iOS 7’s announcement, it quickly looked outdated and needed some visual touch-ups. Today I’ve released the first new set of features for Ohai to make it a better and more beautiful journal, with some of the most heavily requested features.

Read More

About three years ago, I had a simple idea. I wanted an app to keep track of the places I’ve been. Naturally I’ve tried all the services for this, jumping from Gowalla to Foursquare to Path. But they all want you to broadcast your location, all the time. They’re focused on the experience of letting other people knowing where you are. There’s certainly value in sharing your location, but I wanted something that benefited me first.

I built a prototype of this app a few years ago, but it didn’t go anywhere. The secret sauce behind any check-in app is a database full of points of interest (or POIs, meaning places like businesses, restaurants, tourist attractions, etc.), and mine was no different. I didn’t want to rely on a free API of places that could evaporate at any time. Buying API access to one was prohibitively expensive. And shipping without one meant checking-in became a huge data entry process that was not fun. The project got shelved.

Then, a few months ago, my friends over at App.net announced a new API for finding POIs, and attaching metadata about places to posts and private messages. A few months before, they released an API for, among many other things, creating a private timeline of posts for individual accounts. I saw both a way to get a sustainable POIs database and cloud storage for check-in data.

And thus, Ohai was born.

Read More

In the last few years, we’ve seen a pretty significant shift in how we use computers. We’ve gone from primarily using one Internet-enabled device (the PC) to using two (PC + phone) to using three (PC + phone + tablet), and who knows what else we’ll add in the next couple years. Not only are we looking up our data and documents on all these devices, we’re creating data and documents on them, and the time we’re spending to do it on the PC is getting smaller. Effortless and ubiquitous access to data is increasingly important to people.

If your app deals with user’s data, building cloud sync into your app should not be a feature you bolt on to an app – it is the feature. It’s why you will beat competitors or lose hard to them. It’s what will make your app feel effortless, thoughtless, and magical. It’s what will gain a user’s trust, and once you have that, they will sing your app’s praises and never give it up. But to earn that trust, you have to account for sync at every step of the design and engineering of your app.

Developers have a number of choices as to how to build an app around sync. You can use iCloud, you can use a hosted service like Parse, or you can build a custom sync service for your app. Each solution has trade offs. So what should you optimize for?

Read More

Smartphones have replaced lots of types of small devices. iOS and Android have made it easy to build apps that perform all kinds of functions, replacing other standalone devices like media players and GPS. It’s been wondered if they would replace handheld gaming devices, and for many people they have. For awhile, I thought they had, at least for my needs. But after trying to play games on touchscreen-only devices for years, I’ve largely felt unenthused about the deeper and more engaging games that would come from big studios. These games required a higher level of precision control that touchscreens just couldn’t deliver.

The PS Vita caught my attention about a month before its launch in the US. It combines a lot of the best features of smartphones with the controls of console games. It has a gorgeous, large, high-resolution touchscreen (and a back panel that is touch-sensitive), as well as a tilt sensor and cameras for augmented reality games. But it also has almost all of the buttons of a typical PS3 controller, including two analog sticks. Sony managed to cram all of this functionality into a device that, while large, is not too big to fit into my pocket, and with long enough battery life for a busy day interspersed with some gaming. The combination of apps and games (which I will describe as just “apps” for the sake of this review) is powerful, and the hardware power and display size make it a compelling device.

Read More

Adobe is finally putting an end to Flash Player. They’ve announced they’re stopping development of the mobile Flash Player, which is where the future of tech innovation is heading, and the writing is on the wall for desktop Flash Player as well. This is a good thing for a myriad of reasons, both technical and political.

However, it is important to remember that Flash drove much of the innovation on the web as we know it today. When Flash was conceived over a decade ago, the web was a glimmer of what it is today. Creating something visually impressive and interactive was almost impossible. Flash brought the ability to do animation, sound, video, 3D graphics, and local storage in the browser when nothing else could.

Without Flash, MapQuest would not have been able to provide maps for years before Google did in JavaScript. The juggernaut YouTube would not have been possible until at least 2009, four years after its actual launch. Gaming on the web, which has been around as long as Flash, would only now be possible a decade later. Flash enabled developers to create rich user experiences in a market dominated by slow moving browser developers. Even in 2011 Flash exists to provide those more powerful apps to less tech-savvy people who still use old versions of Internet Explorer.

Flash Player itself seemed like a means to an end. Macromedia, and then Adobe who acquired them, sells the tool that you use to build Flash content. Thus, Adobe’s incentive was not to build a great Flash Player, but a pervasive one that would sell its tools. Its technical stagnation provided a market opportunity for browser developers to fill in the gaps that Flash provided. As a result it has a huge market dominance in tools for building rich apps for the web, tools HTML5 lacks.

This puts Adobe in a unique position. As HTML5 continues to negate the need for Flash Player, Adobe has the tools for implementing Flash within HTML5, and the market eager for those tools. Hopefully this move signals that Adobe will be moving in this direction. Because the web DOES need great HTML5 tools for people who aren’t savvy in JavaScript, especially for the people who used Flash to do it previously.

HTML5 offers developers the ability to build high-performance, low-power apps and experiences. Browser innovation has never been faster; Apple, Google, Microsoft, and Mozilla are all competing to bring the best new features to their browsers in compatible ways. But they’re just now filling in many features Flash Player has had for years. Adobe can harness this to help build a better web, and few others can. Hopefully they seize this moment.

JailbreakMe.com is a website that offers visitors the ability to jailbreak their iPhone without a computer-based tether. It does this by exploiting the system-wide ability for applications to read PDF files, where an incorrectly-formatted PDF file can lead a hacker to do anything they want to your system. While this bug CAN be used maliciously to steal all the personal data from your phone, the developers in this instance used it to enable jailbreaking.

Others will tell you why you should or should not jailbreak your iPhone. Others will decry the developers for bringing to light a serious vulnerability in the iPhone OS. In this blog post, I won’t do any of that, but will instead point out some things you should and shouldn’t do if you decide to jailbreak.

Read More

iPhone had the first two store UIs; the iTunes Store for content like music and movies, and the App Store for software. The iPad will add a third, the iBookstore, for buying eBooks. These stores all provide content for users to extend the utility of their device. But each has a pretty different user interaction model for accessing, purchasing, and consuming that content.

  • The iTunes Store is a separate app that is completely distinct from the iPod app. When you find something to buy, prompting you for your iTunes account password. It then adds the purchase to the app’s Downloads tab. Once you have purchased the content, you must then switch back to the iPod app to listen to or watch it.
  • The App Store is a separate app. When you purchase something, it prompts you for your iTunes password, and then exits to the home screen, switching to the screen where the app will live. The state of the download is reflected in the app icon. When the download is complete, you tap the icon on the home screen to use it
  • The iBookstore (the one word is the official name as used by Apple) is not a separate app, but lives within the iBooks app on the iPad. Purchasing content prompts for the iTunes password and downloads in-app, which can be directly accessed after it has finished downloading.

Each type of content follows a different workflow when going from access to purchase to use. If a goal of the iPad’s low price is to drive content sales through the three stores, as some speculate is the case, then the purchase model should be as streamlined for the different types of content. Forcing different workflows will only confuse users who can’t remember which type of content comes from where.

Ars Technica:

ChangeWave queried 4,068 current and potential smartphone consumers last month and noted that a full 21 percent said that they would prefer Android on their next smartphones—a jump of 15 percentage points from the year before. Comparatively, 28 percent of respondents said they would prefer iPhone OS; this makes the iPhone the leader in this category, though this number dropped four percentage points year over year.

Many iPhone developers and Apple enthusiasts are quick to shrug off the Android platform, for a variety of reasons ranging from aesthetic and design, to functionality and developer tools. Many of these criticisms are certainly valid. But iPhone has its own share of problems, and certainly is deficient in many ways to the Android.

With Google’s press conference tomorrow, and CES for the remainder of the week, there will be a lot of focus on the Android platform. It will become a much stronger platform in 2010. It will be interesting to see how Apple responds with iPhone OS 4.0 (which history suggests they’ll probably talk about in March).

Link

VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.

Stylesheets

VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the “active” stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you’ll want to tell your views to update their styles and redraw.

Styles

Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills

    • VSSolidFillStyle – Fills the current shape with a solid color
    • VSLinearGradientFillStyle – Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle – Fills the current shape with a glossy-style gradient between two colors
  • Borders

    • VSSolidBorderStyle – Draws a border around the current shape with a solid color
    • VSBevelBorderStyle – Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle – Draws a border around the current shape with four colors, one for each edge
  • Shadows

    • VSShadowStyle – Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle – Draws a shadow inside the content with a given color, blur, and offset
  • Positioning

    • VSBoxStyle – Adds a margin or padding to the content area
    • VSInsetStyle – Adds edge insets to the content area
  • Content

    • VSTextStyle – Draws text inside the current shape
    • VSImageStyle – Draws an image inside the current shape
    • VSMaskStyle – Clips the drawing area to an image mask
    • VSShapeStyle – Clips the drawing area with a VSShape object

Shapes

Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape – a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape – a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!
Link

There’s been quite a bit of misunderstanding about what Palm’s new WebOS is, versus what it isn’t. So I’d like to dispel some of the questions surrounding it from the information I’ve been able to find on it. There isn’t much I was able to find (not surprising, as the thing was just announced today), but we can draw some conclusions from the information.

From Web Apps to Widgets

Many people will respond with derision at the fact that applications in WebOS are built with HTML, CSS, and JavaScript; given the state of most web applications today, this isn’t hard to understand. However, the biggest reason web apps are crap compared to their desktop equivalent is that web apps have no integration with the host OS. Which means that web apps have a tough time dealing with multiple OS windows, the clipboard, and offline access.

When Apple released Tiger, they shipped with it the popular Dashboard interface. Inside were miniature applications which were also written with HTML, CSS, and JavaScript. There was a slight difference, however; Apple included the means to integrate the Dashboard with JavaScript. One example is how a Dashboard widget will display its settings via a smooth, GPU-accelerated 3D animation where the 2D widget flips over. This is possible because Apple included JavaScript hooks to perform this animation. But the core tools were just the same – HTML, CSS, and JavaScript.

The Mojo Framework

WebOS applications are much more sophisticated than Dashboard widgets, and certainly more so than regular web applications. This is because WebOS includes a set of tools for creating apps, called the Palm Mojo Application Framework. This, at its highest level, is conceptually similar to Cocoa Touch on the iPhone; it provides common functionality to all applications. It’s what will provide all the common code on the device, from data manipulation of stuff like your calendars to the whizzy animation effects you’ll see throughout the interface. It’s the reason that, in most iPhone apps, the scrolling behavior feels exactly the same.

So, from what I can tell, the Mojo framework is an implementation of all of these ideas, using JavaScript as the programming language, and using HTML5 and CSS for drawing to the screen. Despite there being very little information, they do mention the following features on the developer website:

  • apps are installed and run on the device,
  • apps are designed to be multitasked and run in the background,
  • apps have full access to gestures and the touch screen,
  • apps can use a Growl-esque system to display user notifications,
  • apps will have access to sqlite databases for data storage (part of HTML5), and
  • apps can exchange data via a common messaging mechanism.

The Performance Argument

“But won’t it come down to speed?” Yes, it will. However, WebOS is based on WebKit, and likely is using the latest enhancements from the SquirrelFish project. There is a battle royale going on right now between the developers of WebKit, Firefox, Chrome, and Opera for fastest JavaScript interpreter, which means that JavaScript is only going to get faster and faster.

Why go with JavaScript? It provides a low barrier to entry; nobody really needs an SDK to write apps. It makes it very easy to sandbox apps, as the underlying operating system is still invariably written in some form of C, and JavaScript provides no way to break that barrier. And many other reasons, which I talked about last year before the iPhone SDK came out.

tl;dr: JavaScript is just a language. Palm used that to build a system for making applications. They’re nothing like web apps.