When technology vendors do dumb things, you can pretty much count on reading a gleeful retelling of the sordid details in this space. After all, if there’s one thing I’m never short of, it’s opinions. Conversely, when those same vendors do something laudable, I feel obligated to play it both ways and say well done. Today, it’s Apple’s turn over a smart move it’s making in the App Store.
Starting Sept. 7, Apple is pulling the plug on apps that appear to have been abandoned, are multiple iOS versions behind in compatibility updates, or simply don’t measure up to Apple’s grand vision. That’s good news all around. In Apple’s own words, “We are implementing an ongoing process of evaluating apps, removing apps that no longer function as intended, don’t follow current review guidelines, or are outdated.” I urge you to visit that link and read the information carefully.
If you’re a lazy developer who hasn’t invested the necessary time to keep your app up to date for changes in screen sizes and resolution, or leverage features added to iOS over the last several years, you don’t deserve to have your app listed. If that’s you, it’s time for some Swift action lest your app get the boot. Existing users will not lost any app functionality, services will not be interrupted, and in-app purchases will remain enabled. As for new users, well, there won’t be any.
For developers who do invest the time, this is great news. With more than two million apps currently listed and roughly 100,000 new app additions or updates submitted weekly, culling the catalog should help make those that remain a bit more discoverable. And, as you know, the inability for apps to be discovered easily has plagued the App Store for years.
If the long arm of Apple reaches out to you, be warned. You have but 30 days to make it right. After that, the app is zapped. There’s also an even more potentially dire situation for you: If it’s discovered your app crashes on startup, it gets removed from the app store immediately with no grace period.
But wait, there’s more. In the letter that Apple sent to developers (and made public by iOS developer and good samaritan Jake Marsh) the company said app names can no longer exceed 50 characters in length. That means no more stuffing desirable search terms in an app name, regardless of what that app does. It’s a good way to bring some discipline to a Wild West app shopping environment.
Though I don’t know what pushed Apple toward this posture, it’s welcome, especially if you’re a developer hoping and praying you can generate a revenue stream from your beloved app that just can’t seem to get noticed.
Do you develop for the Apple App Store? What do you think of Apple’s desire to clean house? Are your apps up to date? If not, why not? Share your thoughts with us; we’d like to hear from you.
No doubt you’ve read news stories about individual consumers, police departments, and now even hospitals having their computers and data victimized by ransomware , an exploit in which the attacker “kidnaps” and encrypts the victim’s data, demanding payment for the decryption key. As a developer, is there anything you can do about it? The short answer may be no.
So far in 2016, hospitals in California, Kentucky, Maryland, and Kansas have been hit with ransomware attacks. In February, according to NBC News, Hollywood Presbyterian Medical Center had no choice but to fork over $17,000 to the bad guys in order to get its systems back. That’s a big jump from the typical $300 that an individual consumer might be forced to pay. Even a NASCAR team was victimized, forced to pay up to get its data back. It’s enough to drive you in circles, or ovals in NASCAR’s case.
How widespread are ransomware attacks? Consider this June 2016 statement from security software maker Kaspersky. “The number of users attacked with encryption ransomware is soaring, with 718,536 users hit between April 2015 and March 2016: an increase of 5.5 times compared to the same period in 2014-2015.” Yikes. During the same period, users attacked with blockers (ransomware that locks screens) decreased by 13.03%, from 1,836,673 in 2014-2015 to 1,597,395 in 2015-2016, according to Kaspersky.
There’s more. Cisco warns that businesses are unprepared. Security vendor RSA says cloud service providers are becoming a popular target. The U.S. Department of Health and Human Services went so far as to publish information on ransomware, including how to tell if HIPAA has been violated.
Unfortunately, the ubiquitous nature of the Internet of Things technology makes it a completely new fertile ground for ransomware attacks. Earlier this month, two security researchers demonstrated how a residential thermostat can be taken over by ransomware, locking it until a ransom was paid in the form of a Bitcoin. Keep in mind this was nothing more than a proof-of-concept demonstration. But, you know where this is likely headed.
The only way to deal with ransomware is to prevent it in the first place, according Malwarebytes Labs. That means running security software, resisting the urge to click alluring links, and backing up one’s data frequently and regularly. Unfortunately, as an applications developer — and an honest one at that — there isn’t really any proactive or anticipatory defense you can build into an app.
As an app developer, are you advising your organization about the dangers, causes, and prevention of ransomware? Have you or your company been a victim? Share your thoughts; we’d like to hear from you.
Ask Siri “does this make me look fat,” and she’ll answer, “It seems like humans are preoccupied with this. In my dimension, we are more concerned with grey matter that corporeal matter.”
Sigh. I would be nice if developers of mobile apps had access to such profound insight. And now you do. At last, the forthcoming iOS 10 includes SiriKit and an API. You’ll also be able to create app extensions that let users interact with your app directly within messages.
As Apple puts it, “SiriKit enables your iOS 10 apps to work with Siri, so users can get things done with your content and services using just their voice.” But wait, there’s more. “In addition to extending Siri’s support for messaging, photo search and phone calls to more apps, SiriKit also adds support for new services, including ride booking and personal payments.”
Through SiriKit, your app builds an extension that communicates with Siri, as Apple explains, even when your app isn’t running. That extension registers with specific domains and intents. As an example, Apple discusses a messaging app that would register to support the Messages domain, and the intent to send a message. Siri does the heavy lifting, handling the user interaction, including voice and natural language recognition.
Six areas are predefined by Apple for third-party Siri interaction, including ride booking, photo search, VoIP call initiation, messaging, payments, and workouts.
To jump in the fray, you’ll need to download the Xcode 8 beta, which includes the iOS 10 SDK. At the bottom of the SiriKit page, you’ll also want to check out links to SiriKit programming guide, intents framework reference, intents UI reference, and tutorials.
As for messages, according to Apple, “Users will have easy access to your apps without having to leave Messages. They can conveniently share content, edit photos, play games, send payments, and collaborate with friends within a custom interface that you design.”
I certainly don’t care about the game play aspect or the ability to paste in stickers, but collaboration with work colleagues could provide powerful new capabilities for enterprise-class applications. Editing photos can also be leveraged for applications in, say, the insurance industry, where an adjuster can make annotations when photographing a damaged vehicle.
There’s a ton of documentation for creation of applications with iOS 10, including code samples, framework references, DemoBots for games, and much more. Time to get reading. And coding.
Have you already started building new apps or updating existing apps for iOS 10? What capabilities are you adding? Let’s get the discussion going; we’d like to hear from you.
And no, I don’t think it makes me look fat.
With the ability to quickly conjure up an online interactive survey thanks to software as a service (SaaS) technology, any developer or business can almost instantly start polling potentially hundreds or millions of respondents with dozens of questions. Do you really need all that data?
Designing surveys whose questions do not introduce bias or ambiguity on the part of the survey sponsor is not an easy task. It’s a skill, a profession. You’ve got to figure out what questions to ask and how to word them properly. You need to provide for all possible answers (including “prefer not to answer” and “don’t know/don’t care”). You can’t allow answer choices to overlap (0-10 and 10-20 instead of 11-20). If you’re tasked with building a survey, you might want to brush up on the seven sins of survey question writing and how to avoid them. Of course, there are hundreds of other online resources.
Questioning the questions might not be an app developer’s job, but your logical mind is likely better-suited for finding the kinds of mistakes that could render a survey’s results useless.
What got me thinking about applying a developer’s keen eye to the logic of survey questions? It’s the surprisingly invasive nature of a survey I just took on the subject of interchangeable lens DSLR (digital single-lens reflex) cameras.
At 40 minutes, the survey was way too long and complex. But, what really bothered me was the invasive nature of some introductory questions: race, marital status, household income, number of children, technology devices in my home (including Segway — really?), and my favorite, “general statements about different attitudes you might have toward life in general.”
Are these really germane to a survey on cameras and lenses? Perhaps. Even if they are valid from a statistical analysis perspective, they sure seem nosy. Let me put it another way. If this was a survey about which cloud application development tools you like best, would you be willing to answer those very same questions?
Have you been asked to build surveys for your company? Did you find logic errors or other problems with any of the questions? If so, did you speak up? Share your thoughts; we’d like to hear from you.
When you write an app for Apple’s iOS there’s no ambiguity. To say the operating system and its distribution are tightly controlled is an understatement. It’s Apple’s way or the highway. Not so with Android. Fragmentation and lack of corresponding offerings from device makers is out of control. It’s a complete mess for developers.
How bad is it? It’s bad enough for Salesforce to declare that it will support only Samsung Galaxy and Google Nexus devices. That’s pretty drastic and should send a clear and frightening message to all that play in the Android space to get their acts in sync. Indeed, Android fragmentation is hurting its case for widespread enterprise adoption, a problem that iOS does not face.
The problem is years in the making. With each maker of devices that run Android able to tweak the user interface as they see fit, and their power as to when — or even if — to launch any new version, the permutations in terms of the operating system, its many versions, and the cornucopia of devices on which it runs are likely in the thousands. It’s not something app developers should have to put up with.
Consider some recent research from Statista. For the period May 2 to May 9, 2016, the distribution of Android versions that accessed the Google Play store looked like this: KitKat 4.4, 32.5%; Lollipop 5.1, 19.4%; Lollipop 5.0, 16.2%; Jelly Bean 4.1.x, 7.2%; Jelly Bean 4.3, 2.9%; and smaller numbers from Gingerbread, Ice Cream Sandwich, and Froyo.
Yes, it’s a mess. It’s a lot of different versions being used actively and concurrently. What really sticks out is that the largest group, KitKat, is two generations behind the most-recent Android version.
For the very same weeklong period, the breakdown of iOS devices that accessed the Apple App store looked like this: iOS 9, 84%; iOS 8, 11%, all earlier versions, 5%. (That last group includes my iPod touch 4th generation, which ceased getting updates after iOS 6.1.3.) As long as your app is compatible with iOS 8, you’ve got 95% of the market covered.
This is especially problematic because developers are writing for a base of billions of devices — 7.1 billion mobile phones in 2015 worldwide heading to 8.6 billion in 2021, according to Ericsson. That doesn’t include tablets, which adds nearly another two billion. This does contrast with legacy corporate applications that were intended to run on only one mainframe computer.
Fragmentation is an old story
OS fragmentation isn’t anything new. Many years ago, at a trade event at the New York Marriott Marquis, between mouthfuls of baby lamb chops and jumbo shrimp, I asked Bill Gates about his perception of the then-current state of Unix and what it meant for developers. “Unix is a hundred different things that don’t talk to each other,” he said.
The sentiment, if not the exact number, was right, of course. With Hewlett-Packard’s HP-UX, IBM’s AIX, Silicon Graphics’ IRIX, Sun Microsystems’ Solaris, Compaq’s Tru64, Apple’s A/ux, AT&T’s System V, SCO’s UnixWare, and others all in competition with each other, writing an application that ran well on all platforms bordered on impossibility. Add the messy ownership wars with Unix Systems Labs and Novell into the mix, and it gets even uglier.
As a mobile app developer, what are the roadblocks you run into when developing for Android? Does the proliferation of different versions from different vendors create problems? And in comparison, what is your experience with iOS? Share your thoughts; we’d like to hear from you.
My grandson is just a tot, but he already understands the concept of multisource integration. Chicken nuggets from here, ketchup from there, a fork from, well, somewhere, and you’ve got yourself a comprehensive system. Call it the day-care version of APIs.
For us grown-ups, APIs make the world go round. My standard example is a culinary recipe app that pulls in data from numerous sources — weather, geographic, day of year, time of day, locally available farm-fresh veggies, supermarket promotions, user’s likes and dislikes — to recommend a recipe of the day to the app user. It’s a data integration example I can explain to anyone. And, of course, APIs make it possible.
Last week, Red Hat proved the increasing importance of APIs in app development beyond any doubt with its acquisition of API management tools vendor 3scale. In my exclusive joint interview with Mike Piech, Red Hat’s vice president of middleware, and 3scale CEO Steve Willmott, they explained why everything that developers touch is predicated upon APIs.
Willmott said over the last 18 months he had witnessed APIs becoming the backbone of many infrastructures, but that IT often lacked the means to manage, track, and secure their APIs. Piech agreed, saying that as recently as two years ago, API management rarely came up as a top-level requirement. That has changed as disparate infrastructures and services — on-premises, public and private cloud, software as a service, analytics as a service, data storage as a service, etc. all have to interoperate.
If it can be summed up in a single sentence, Willmott gets the gold medal, “APIs are the glue between on-premises and cloud-based components,” he said. I’ve thought of APIs more along the lines of conduits than glue, but Willmott is spot-on with his assessment.
The message here is not that APIs are hot or necessary. We all know that. What we’ve collectively not done superbly is manage the ever-growing collection or public and private APIs that enterprises purchase, subscribe to, or develop internally. Just as you need to know what keys are on that keychain in your pants pocket or handbag, you also need to know that your keychain is secure. API management is no different.
Cloud consultant David Linthicum is also an advocate of creating and instituting an active API management strategy. “API management should be a priority for any organization using the cloud,” he writes. He’s right.
It’s time for a robust discussion about APIs. What has APIs enabled that you could not do before? Who is testing your APIs for accuracy and security? And, to leverage the message of Red Hat’s 3scale acquisition, how are you managing your API portfolio. Share your thoughts; we’d like to hear from you.
Wi-Fi is what we all talk about. It’s what we all write about. It’s built into every wireless device. Your apps depend on it. But, what about Bluetooth? If you haven’t recently thought about leveraging the power of Bluetooth in your apps, the time to think anew is here.
The launch of Bluetooth 5 is just a few days away (June 16). This is a big deal. Bluetooth 5 offers the promise of up to double the range and transfer speeds up to four times faster than the current incarnation of the technology.
According to Mark Powell, executive director of the Bluetooth Special Interest Group (the organization that oversees the Bluetooth standard, its trademarks, and licensing), BT 5 will, “double the range and quadruple the speed of low energy Bluetooth transmissions.” But, that’s not all. BT 5 will also broaden its capabilities for connectionless services, such as location-relevant information and navigation.
That’s great news. A year ago, I wrote about how Florida’s Sarasota Memorial Health Care System was using Bluetooth Low Energy with iBeacon to pinpoint people’s precise current locations within the sprawling multistory facility and display that information on a tablet or smartphone using cloud-resident maps. Think of it as an interactive “you are here” handheld map to help prevent visitors from getting lost. Bluetooth works because it is highly precise. GPS, for example, doesn’t work nearly as well for determining elevation — which floor of a multistory building you’re currently on.
BT 5 is also beefs up its so-called “advertising packets” technology. This isn’t about product advertising, but about a device, such as a Bluetooth speaker being able to more easily say “I’m a speaker and I’m nearby,” in essence advertising its presence. This will help devices that aren’t already paired to more easily find each other.
I don’t yet know if BT 5 is an upgrade to existing hardware, or if new hardware will be required. If it’s the latter, the impact won’t happen until phones and other devices go through a couple of refresh cycles. The capability might be in Apple’s next set of phones, or not until 2017. It’s too early to know. Either way, Bluetooth shouldn’t be overlooked in your next mobile app development project.
Share the ways you’ve leveraged the power of Bluetooth and how extended range and faster transfer speeds could alter your thinking. We’d like to hear from you.
This week’s Cloud Computing Expo in New York isn’t among the IT industry’s largest gatherings, but it’s one of the most important. With nary a CFO or CIO among the attendees, this is a gathering aimed squarely at those of you working down in the trenches of cloud application development, testing, and operations. Walk into almost any educational session and you’d hear about IoT, Industrial IoT, storage and how to deal with huge amounts of it, testing, microservices, and containers.
One shift we are likely to see over the next few years is that of cognitive computing, where the nature of the data dictates how it should be handled. For decades, we’ve designed and built applications that process data in predetermined ways, based on our expectations of what the data looks like or should look like. What I’ve learned is that we are in a new era, where forces like social media, text messaging, multimedia, and sensor readings are delivering to applications data that is not just unstructured, but wildly variable in its content and format. What cognitive software needs to do is be ready when the data says “here’s what you need to do with me.” That is the essence of cognitive computing, where the data directs how the application should function. In other words, traditional applications are based on the past and cannot anticipate the future.
As cloud consultant Judith Hurwitz put it in her presentation, “cognitive computing is a problem-solving approach that uses hardware or software to approximate the form or function of natural cognitive processes.” What that means is systems designed based on data and letting the data lead the logic. Systems end up being designed to morph as they learn about the ever-changing patterns of data. And here’s a good one: Cognitive systems assume there is not just one correct answer, but is more probabilistic in nature, using hypotheses based on the data itself. At its core, this is machine learning where a system’s performance can improve based on exposure to patterns in the data rather than on explicit program code.
One thing I found interesting is that several presentations at Cloud Computing Expo touched on this idea of cognitive computing without ever using that particular label. As one presenter said, when you have an influx of text-based data, the processing applications must have the capability of differentiating between “feet” as a unit of length and as those things at the ends of your legs. Same word, different meaning. Cognitive systems can learn from such patterns, usages, and anomalies, and they can morph or evolve as more data is ingested and analyzed.
For the applications that you develop, does this thinking make sense? Are you building cognition facets into your work as a means of being able to do something, anything, with data that seemingly has no historical antecedents? Share your thoughts about the rapidly advancing field of cognitive computing. We’d like to hear from you.
Let’s have a little fun today and look at how the cloud is being used in ways that some might consider, well, out of the ordinary. Sure, anyone can conjure up a cloud-based system for purchasing books online, but what about using the ol’ smartphone to manage cows down on the farm?
SCR Dairy began in 1980 making equipment for the dairy-farming industry, stuff like detachers and pulsators, whatever they are. Today, the company offers cloud-based mobile applications for herd management, improving successful pregnancy rates, health tracking, and more. The latest advancement from the Israeli company is a series of mobile apps to — and stop me if you’ve “herd” this before — “improve productivity, reduce costs, and gain more control.” Whatever the industry, this golden troika of goals never seems to change. The company’s tagline is “make every cow count.” Like you, I didn’t know they could.
ETWater, which previously talked to me about the IoT talent shortage, designs cloud-based IoT smart lawn irrigation systems. The Novato, Calif. company builds Wi-Fi controllers that manage the zones of lawn sprinkler systems. It uses an integration analytics engine to calculate when and how much to water, based on dozens of metrics pulled in via APIs from a variety of sources. These include weather, humidity, time of year and day, sun and wind conditions, sensor readings of soil moisture levels, and a whole lot more. If you manage golf courses or office parks, it’s a clever and welcome use of cloud computing and data integration. At home, I can just look out the window.
If you’ve ever stood in the produce section and asked yourself, “Gee, are we out of kohlrabi,” Samsung has you covered. The Korean industrial giant’s new line of Family Hub refrigerators are equipped with, count ’em, three cameras that take a photo each time you close the fridge or freezer door. Use your smartphone to pull up an image while you’re at the supermarket or on the way home from work. Isn’t this what the cloud is all about? It certainly gives lends a whole new meaning to your subject saying “cheese” as the pic is snapped. Perhaps Samsung could link the cameras to SCR Dairy so we can have fresh milk from the farm on auto-replenishment. And, at last, you’ll know for sure if the light really does go out when you shut the door.
Finally, there’s the concept of paying by the foot. Literally. If those $400 running shoes you covet are out of your budget, you might be able to sign up for a pay-as-you-go plan based on how many steps you take or miles you run. The same might be true for those outrageously expensive high-performance tires you’d like to put on the family chariot. We’re not quite there for these two yet, but microbilling based on usage is very real. Without the cloud and Wi-Fi to do periodic data uploads, none of this works.
Well, enough of the fun stuff. The point is that what we can do with technology is limited only by our collective imaginations. Otherwise, we might still be carrying boxes of tape cassettes or three-ring binders filled with CDs on our journeys.
What are the truly unusual cloud apps that you’ve worked on and what was it about the development process that you found irresistible? Share your stories with us; we’d like to hear from you.
SAP and Apple. Apple and SAP. A good partnership offers benefits to each party. And that’s exactly what’s happening here. Let’s not forget the key third party not mentioned — cloud applications developers. For developers everywhere, there’s a lot to like.
SAP gets a lot from this union, starting with an express lane to develop its own enterprise apps for the iOS platform, encompassing iPhone and iPad (and perhaps Macs if OS X should eventually be supplanted by iOS). SAP also gets under-the-hood access to Apple’s XCode and Swift languages, a nice pairing with SAP’s own HANA in-memory applications platform and the Fiori UX (user experience) design environment. The real prize, however, is that SAP gets access to the 10 million enthusiastic developers writing for and who have expertise in iOS. That’s a lot of developers with a lot of non-traditional ideas about what apps can do.
Sam Yen, SAP’s chief design officer, is excited about the possibilities. “We’re trying to take the enterprise experience to the next level and capitalize on people using apps on their iPhones at home and the user experience they enjoy from that,” he said. “With our Fiori efforts, we want to optimize for mobile scenarios.”
For its part, Apple gets access to SAP’s global enterprise customer base, currently around 310,000 and an army of applications developers 2.5 million strong. Many of those developers are expected to create a new generation of purpose-built, enterprise-class applications that leverage SAP’s database and server-side power. It’s a huge vote of confidence in iPad and iPhone, both of which have seen sales wane in recent times. If the consumer market for tablets is near the saturation point, that’s likely not so in the enterprise. If a large, multinational corporation is going to equip thousands of in-the-field employees with tablets running custom apps, this partnership (and the similar one Apple struck with IBM in Dec. 2015) may sway the choice among tablets running iOS, Android, or Windows.
But wait, there’s more — a new SDK and a training academy.
The two companies are creating a new SAP HANA Cloud Platform SDK exclusively for iOS. It should provide developers with the tools to build custom iOS apps for iPhone and iPad based on the SAP HANA Cloud Platform, SAP’s open platform as a service. Add to that a new SAP Fiori for iOS design language to create apps that, in Yen’s words “look beautiful.”
Finally, expect to see a new SAP Academy for iOS by year’s end to help train developers.
Analysts are bullish. The union is seen as benefiting both companies. Jeffrey Hammond, a Forrester Research vice president and principal analyst who serves development professionals, told me, “This is good news for SAP customers who have struggled through many incarnations of SAP’s mobile strategy.”
What do you think? If your business is an SAP customer, we’d sure like to get your opinion. There’s a comment box just below that’s waiting for your feedback.