Cheat sheet for getting the weekday number from NSDate:

/* get the Gregorian calendar */
NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
/* NSDateComponents lets you get the weekday number, day of month, etc. from NSDate. */
NSDateComponents *comps = [gregorian components:NSWeekdayCalendarUnit fromDate:[NSDate date]];
// get the weekday number. It will be from 1 to 7
NSInteger weekday = [comps weekday];

In iOS, depending on which region is selected in the device settings, the week starts either on Monday, as in Russia, or on Sunday, as in the US. If you only need to output the short name of the weekday, for example: Mon, Tue, Wed, Thu, you can do it like this:

NSDateFormatter *weekdayDateFormatter = [[NSDateFormatter alloc] init];
[weekdayDateFormatter setDateFormat: @"EE"];
NSLog(@"%@", [weekdayDateFormatter stringFromDate:dateFromString]);

I'll leave another cheat sheet in the form of a link. Network Link Conditioner is a tool from Apple from the Hardware IO Tools for Xcode set. It lets you limit connection speed in macOS. You can test, for example, how an app behaves under EDGE connections or worse. The same thing exists in the Developer section of iOS settings, but that is on the device, while this is in OS X.

By the way, the same set also contains a simulator for HomeKit.

Another cheat sheet so I can quickly find it later, just in case. As is well known, in Xcode you can run your own bash scripts while building a project.

These 2 lines of code allow you to automatically increment the build number in the app:

buildNumber=$(git rev-list --all | wc -l)

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

The first line counts the number of commits in the git repository. The second writes that number to the target's .plist file as the build number. Each new commit increments the build number by one. This is one way to do it.

Put it into the required target's Build Phases.

So, in February Yandex forcibly moved all Yandex.Subscriptions users to the Yandex.News service. Without warning, and the whole thing turned out pretty badly. The web version became unavailable. But the API kept working, and the Yandex folks only said that it would continue working. They kept quiet about deadlines and plans. First, new RSS entries stopped being pulled in and the API gave access only to old entries, and then they sent everyone emails saying that on March 31, 2015 they would shut down the API too. Which is what happened. So I removed the iPodpiski app from the App Store and want to sum up some results for myself and for the record.

I wrote the app in spring 2014 in about a week, coding in the evenings. It appeared in the App Store on April 17, 2014, which I happily wrote about on my site and in a post on Habr. The post got a +15 rating and brought some downloads and feature requests. The app fell 17 days short of its first birthday :)

Over that year there were:

1321 downloads of the app and only 496 updates when I released new versions. Not much, but then this is not a mass-market app. RSS is generally considered a technology for robots and geeks. The overwhelming majority of users were from Russia. In 2nd and 3rd place were the US and Ukraine, tied. Record: 77 installs in one day.

1431.42 rubles of revenue from in-app purchases. Initially the app was free, but with ads and a paid option to disable them. Of my 4 apps in the App Store, this is the worst result. On the other hand, getting some money for learning, gaining experience, and solving one of your own problems is not bad either :)

Most of the time the app was in the Top 200 in its category (News) in Russia. The screenshot above shows the highest positions it managed to crawl to in the charts.

Ratings were not great. I never asked people to rate the app anywhere, so ratings were left either by enthusiasts and friends, or by dissatisfied users. Unfortunately, I missed a very annoying bug. When the app launched in portrait mode, the «All Subscriptions» button simply did not appear. As a result, the user saw only the welcome screen and the paid «remove ads» button :) Sad and funny at the same time. I myself constantly used the app in landscape mode and simply did not notice this problem, but I got reviews like «only the ads work».

Most of the requested features I never managed to implement because of lack of time. When you spend the whole day doing web development, it is hard to switch to mobile in the evening, especially when you are tired after work.

The app shows ads from AdMob. Over the year there were only 71135 ad impressions, which brought in $23.87. In other words, the in-app purchase to disable ads brought in more money than the ads themselves :)

So those are the modest results.

Since Yandex shut down its Yandex.Subscriptions service and forcibly moved everyone to Yandex.News, I think this is the end for iPodpiski. Unless they make a public API for Yandex.News. If it is good enough for a port, I'll try to move iPodpiski to the new API. But there is no API yet. The Yandex.Subscriptions API itself still works for now, but they have stopped collecting new news from RSS feeds. The latest news I have there is from February 5-6. I have switched to Feedly myself. Thanks to everyone who used it :)

UPDATE: an email arrived saying that the subscriptions API will be shut down on March 31. Apparently I'll have to remove the app from the App Store too.

A note about how in iOS 8 you now have to request permission to use geolocation differently.

For example, some old code like this:

locationManager = [[CLLocationManager alloc] init];
locationManager.delegate = self;
[locationManager  startUpdatingLocation];

In iOS 8, on first launch it will not ask the user for permission to use geolocation. It will simply ignore this code, and you will not get the location in the app without any warnings.

In iOS 8, you now have to use one of these two methods:

[locationManager requestWhenInUseAuthorization];
[locationManager requestAlwaysAuthorization];

The first requests permission to use geolocation only while the app itself is actually running (when the user has launched it and is inside it). The second also requests permission to use geolocation in the background, or even when the app is no longer running. The second includes the first. If you do not need to track the user constantly and in the background, the first one is enough.

Next, to use one of these methods, you need to add a new item to your Info.plist:

Key: NSLocationWhenInUseUsageDescription or NSLocationAlwaysUsageDescription, depending on which permission type you chose. Value - explanatory text describing why you need permission to use geolocation. You can leave it empty, and then the user will see the standard system text. Or you can fill in your own explanation, and then your text will be shown when requesting permission. In principle, this is convenient: you explain to the user why, they understand it, and you have a better chance that they will allow it.

// locationManager must be a class property, otherwise it gets released
locationManager = [[CLLocationManager alloc] init];
   locationManager.delegate = self;
   locationManager.desiredAccuracy = kCLLocationAccuracyBest;
   
   if ( [CLLocationManager authorizationStatus] == kCLAuthorizationStatusNotDetermined ) {
      
      if ( [locationManager respondsToSelector:@selector(requestAlwaysAuthorization)] ) {
         [[UIApplication sharedApplication] sendAction:@selector(requestAlwaysAuthorization)
                                                    to:locationManager
                                                  from:self
                                              forEvent:nil];
      }
   }
   
   [locationManager startUpdatingLocation];