Unit Testing in iOS using XCTest framework.

https://developer.apple.com/library/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/UnitTestYourApp/UnitTestYourApp.html

PSPDFKit for rendering PDF files

Why Choose PSPDFKit?

Time to Market

PSPDFKit supports blazingly fast PDF viewing, adding annotations, and filling out forms. Our battle-tested code is trusted by Box, Dropbox, Evernote, and hundreds of other companies. Benefit from a solid, tested codebase and incorporate all those advanced features into your own app. Integrating PSPDFKit will save you at least one year compared to developing the technology in-house.

Easy Integration

Almost every aspect of PSPDFKit is customizable and designed from the ground up to offer maximum flexibility while also maintaining simplicity. The developer-friendly API exposes a lot of features that'll cover just about every use case you can think of. Focus on the unique parts of your product and build on a well-documented codebase that is heavily field tested and “just works.”

Five Tools for iPhone app design

The market for iPhone apps is abundant, with over 1.2 million apps available in the app store. But, if your app has a great user experience and becomes popular, like Instragram and Disney Creativity Studio, it can be quite lucrative. While there are plenty of good ideas for new apps, it’s imperative to execute the Design and Development well to increase the chances of success. The recommended path would be to hire an experienced firm with a proven track record, such as Worry Free Labs to help with Design or Development. But if you are working on a limited budget, there are many tools and programs available that can help you Design and Visualize how the end product should function and look.

Below are five such tools that help assist you with the Design process.

1. Invision

 

Invisionapp is powerful prototyping tool that allows you to create and design a clickable prototype of a mobile or web application. This tool allows you to quickly transform your designs into beautiful, fully interactive prototypes complete with gestures, transitions & animations for web, iOS & Android. The tool helps coordinate communication and feedback and has a method of marking which screens are approved for the next phase of design or development. Worry Free Labs’ designers use this tool on a regular basis and it helps our team show clients how the app will work and look. Its also a great tool for our development team because it allows them to better plan and understand how the final product will work.

2. Balsamiq 

Balsamiq  is a tool that allows users to quickly create a wire frame mock-up of their app idea. While the functionality of an app is always important, app designers will need to ensure that their app has a great user experience. Balsamiq will help make sure you have just that before you spend precious time writing code. It also has a number of third party plugins and tools that allow for easy collaboration, making it quick and easy for teams of developers to use Balsamiq and share they wire frame mock-ups with one another.

3. Appgyver

Appgyver is another app that allows you to quickly create wire frame mock-ups of your layout and share them with your team, like Balsamiq. However, unlike Balsamiq, Appgyver also offers a program called Steroids. This is a program that allows you to develop working apps in HTML 5 rather than in Objective C, meaning it could help make the development process easier for those who already know HTML 5 and are still learning Objective C. There have been over 20,000 apps built with this program, and could help developers very much in their endeavors to release money-making apps.

4. Blueprint

Blueprint is a very useful tool to have when planning your prospective app. While the list has already contained plenty of tools to help you visualize the layout of your app, Blueprint is a useful tool for visualizing the functional side of the app. This tool helps you to make a very easy-to-follow and understand story board for your app and its functions. It uses an easy to learn drag and drop method of organizing the pages of the app, and allows for arrows and lines to placed. Blueprint helps you visualize your app and is perfect for testing the functions and navigation before having to write and revise the code.

5. Xojo

Xojo is a program that can help save a lot of time when building your app. Quite a bit different from the previous tools, Xojo is a desktop app development toolkit that allows you to use a drag and drop interface to create your app. In other words, if you’re still learning and perfecting your use of code, Xojo will let you design an app without worrying about the code yourself.

Custom Webview (UIWebview)

DLWebView - a drop-in browser component

DLWebView is a UIViewController subclass, which you can use in conjunction with a UINavigationController. It features a refresh button, back/forward buttons as well as a title label. Those buttons are added to the UINavigationBar, when DLWebView is loade

Custom Grid View in iOS like Collection View .

An grid view for iPhone/iPad, designed to look similar to NSCollectionView.

https://github.com/AlanQuatermain/AQGridView

Live management of your crash reports for Mac OS X and iOS.

Live management of your crash reports for Mac OS X and iOS.

http://quincykit.net/

Augmented Reality Framework

This is the tutorial will give complete understanding about Augmented Reality framework and usage of it..

https://metaio.app.boxenterprise.net/SDK-Mac


Please find the tutorials to learn and implement the "The Metaio" framework.

http://dev.metaio.com/creator/tutorials/_ga=1.140490547.101472107.1405935762

OBJECTIVE-C keywords

OBJECTIVE-C keywords

OBJECTIVE-C keywords

Objective-C is a superset of C language, so program written in c and C++ should compile as objective-c. It provides some additional keywords, to avoid conflict with keywords in other language it uses ‘@’ at the beginning of keyword. These keyword are called Compiler Directives.

Directives used to declare and define classes, categories and protocols:

• @interface used to declare of class or interface.
•                                 
•  @implementation used to define a class or category.
•  @protocol used to declare a formal protocol.
• @end ends the declaration, definition, category or protocol.
• 
  
• Directive used to specify the visibility of the instance. Default is @protected.
• @private Limits the scope of an instance variable to the class that declares it.
• @protected Limits instance variable scope to declaring and inheriting classes.
• @public Removes restrictions on the scope of instance variables.
• Exception handling directives.
• @try Defines a block within which exceptions can be thrown.
• @throw Throws an exception object.
• @catch Catches an exception thrown within the preceding @try block.
• @finally A block of code that is executed whether exceptions were thrown or not in a @try block.
• Directive used for particular purpose.
• @class Declares the names of classes defined elsewhere.
• @selector(method_name) It returns the compiled selector that identifies method_name.
• @protocol(protocol_name) Returns the protocol_name protocol (an instance of the Protocol class). (@protocol is also valid without (protocol_name) for forward
• declarations.)
• @encode(type_spec) Yields a character string that encodes the type structure of type_spec.
• @"string" Defines a constant NSString object in the current module and
• initializes the object with the specified 7-bit ASCII-encoded string.
• @"string1" @"string2" ...
• @"stringN" Defines a constant NSString object in the currentmodule. The string
• created is the result of concatenating the strings specified in the two
• directives.
• @synchronized() Defines a block of code that must be executed only by one thread
• at a time.

Image Caching in iOS (SDWebImage vs FastImageCache)

iOS image caching. Libraries benchmark (SDWebImage vs FastImageCache)

1. Introduction

In the past years, iOS apps have become more and more visually appealing. Displaying images is a key part of that, that’s why most of them use images that need to be downloaded and rendered. Most developers have faced the need to populate table views or collection views with images. Downloading the images is resource consuming (cellular data, battery, CPU, …), so in order to minimize this the caching model appeared.

To achieve a great user experience, it’s important to understand what is going on under the iOS hood when we cache and load images.

Also, the benchmarks on the most used image caching open source libraries can be of great help when choosing your solution.

2. Classical approach

• download the images asynchronously
• process images (scale, remove red eyes, remove borders, …) so they are ready to be displayed
• write them on disk
• read from disk and display them when needed

// assuming we have an NSURL *imageUrl and UIImageView *imageView, we need to load the image from the URL and display it in the imageView
if ([self hasImageDataForURL:imageUrl] {
  NSData *data = [self imageDataForUrl:imageUrl];
  UIImage *image = [UIImage imageWithData:imageData];
  dispatch_async(dispatch_get_main_queue(), ^{
    imageView.image = image;
  });
} else {
  [self downloadImageFromURL:imageUrl withCompletion:^(NSData *imageData, …) {
    [self storeImageData:imageData …];
    UIImage *image = [UIImage imageWithData:imageData];
    dispatch_async(dispatch_get_main_queue(), ^{
      imageView.image = image;
    });
  }];
}

FPS simple math: 

• 60 FPS is our ideal for any UI update, so the experience is flawless
• 60FPS => 16.7ms per frame. This means that if any main-queue operation takes longer than 16.7 ms, the scrolling FPS will drop, since the CPU will be busy doing something else than rendering UI.

3. Downsides of the classical variant:

• loading images or any file from the disk is expensive (disk access is usually from 10.000 to 1.000.000 times slower than memory access. See comparison here. If we refer to SSD disks, those can come closer to RAM speeds (like 10 times slower), but at this point no smartphone or tablet is equipped with an SSD unit.
• creating the UIImage instance will result in a compressed version of the image mapped to a memory section. The compressed image is small and cannot be rendered. If loaded from disk, the image is not even loaded into memory. Decompressing an image is also expensive.
• setting the image property of the imageView in this case will create a CATransaction that will be committed on the run loop. On the next run loop iteration, the CATransaction involves (depending on the images) creating a copyof any images which have been set as layer contents. Copying images includes:
  • allocating buffers for file IO and decompression
  • reading disk data into memory
  • decompressing the image data (results the raw bitmap) – high CPU consumer
  • CoreAnimation uses the decompressed data and renders it
• improper byte-aligned images are copied by CoreAnimation so that their byte-alignament is fixed and can be rendered. This isn’t stated by Apple docs, but profiling apps with Instruments shows CA::Render::copy_image even when the Core Animation instrument shows no images copied
• starting with iOS 7, the JPEG hardware decoder is no longer accessible to 3rd party apps. This means our apps are relying on a software decoder which is significantly slower. This was noticed by the FastImageCache team on their Github page and also by Nick Lockwood on a Twitter post.

4. A strong iOS image cache component must:

• download images asynchronously, so the main queue is used as little as possible
• decompress images on a background queue. This is far from being trivial. See a strong article aboutbackground decompression
• cache images into memory and on disk. Caching on disk is important because the app might be closed or need to purge the memory because of low memory conditions. In this case, re-loading the images from disk is a lot faster than downloading them. Note: if you use NSCache for the memory cache, this class will purge all it’s contents when a memory warning is issued. Details about NSCache here http://nshipster.com/nscache/
• store the decompressed image on disk and in memory to avoid redoing the decompression
• use GCD and blocks. This makes the code more performant, easier to read and write. In nowadays, GCD and blocks is a must for async operations
• nice to have: category over UIImageView for trivial integration.
• nice to have: ability to process the image after download and before storing it into the cache.

Advanced imaging on iOS

To find out more about imaging on iOS, how the SDK frameworks work (CoreGraphics, Image IO, CoreAnimation, CoreImage), CPU vs GPU and more, go through this great article by @rsebbe.

Is Core Data a good candidate?

Here is a benchmark of image caching using Core Data versus File System, the results are recommending the File System (as we are already accustomed to).

Just looking at the concepts listed above makes it clear that writing such a component on your own is hard, time consuming and painful. That’s why we turn to open source image caching solutions. Most of you have heard of SDWebImage or the new FastImageCache. In order to decide which one fits you best, I’ve benchmarked them and analysed how they match our list of requirements.

5. Benchmarks

Libraries tested:

• SDWebImage
• FastImageCache
• AFNetworking
• TMCache
• Haneke

Note: AFNetworking was added to the comparison because it benefits of disk caching from iOS 7 (due to NSURLCache).

Scenario:

- for each library, I made a clean install of the benchmark app, then started the app, scroll easily while all images are loaded, then scroll back and forth with different intensities (from slow to fast). I closed the app to force loading from disk cache (where available), then run the same scrolling scenario.

Benchmark app – project:

- the demo project source can be found on Github under the name ImageCachingBenchmark, together with the charts, collected data tables and more.
- please note the project from Github had to be modified as well as the image caching libraries so that we know the cache source of each image loaded. Because I didn’t want to check in the Cocoapods source files (not a good practice) and that the project code must compile after a clean install of the Cocoapods, the current version of the Github project is slightly different from the one I used for the benchmarks.
- if some of you want to rerun the benchmarks, you need to make a similar completionBlock for image loading for all libraries like the default one on SDWebImage that returns the SDImageCacheType.

Fastest vs slowest device results

Complete benchmark results can be found on the Github project. Since those tables are big, I decided to create charts using the fastest device data (iPhone 5s) and the slowest (iPhone 4).

iPhone 5s results

 

iPhone 4 results

 

Summary

Results	SDWebImage	FastImageCache	AFNetworking	TMCache	Haneke
async download	✓	✗	✓	✗	✓
backgr decompr	✓	✓	✗	✗	✗
store decompr	✓	✓	✗	✗	✗
memory cache	✓	✓	✓	✓	✓
disk cache	✓	✓	NSURLCache	✓	✓
GCD and blocks	✓	✓	✓	✓	✓
easy to use	✓	✗	✓	✗	✓
UIImageView categ	✓	✗	✓	✗	✓
from memory	✓	✗	✓	✗	✓
from disk	✗	✓	✗	✗	✗
lowest CPU	✓	✗	✗	✗	✓
lowest mem	✓	✓	✗	✗	✓
high FPS	✓	✓	✓	✗	✓
License	MIT	MIT	MIT	Apache	Apache

Table legend:

- async download = support for asynchronous downloads directly into the library
- backgr decompr = image decompression executed on a background queue/thread
- store decompr = images are stored in their decompressed version
- memory/disk cache = support for memory/disk cache
- UIImageView categ = category for UIImageView directly into the library
- from memory/disk = top results for the average retrieve times from memory/disk cache

6. Conclusions

- writing an iOS image caching component from scratch is hard
- SDWebImage and AFNetworking are solid projects, with many contributors, that are maintained properly. FastImageCache is catching up pretty fast with that.
- looking at all the data provided above, I think we can all agree SDWebImage is the best solution at this time, even if for some projects AFNetworking or FastImageCache might fit better. It all depends on the project’s requirements.