On this page:
- What's new?
- Description
- Supported Languages
- Supported Versions
- Supported iOS and third-party frameworks
- Function Point, Quality and Sizing support
- CAST AIP compatibility
- Supported DBMS servers
- Prerequisites
- Dependencies with other extensions
- Download and installation instructions
- Packaging, delivering and analyzing your source code
- Automatic exclusion of test and external dependency files from analysis
- What results can you expect?
- Known Limitations
Target audience:
Users of the extension supporting iOS mobile applications written in Swift built with Xcode.
Summary: This document provides information about the extension supporting iOS mobile applications written in Swift built with Xcode.
What's new?
Please see the following pages for information about new features/changes, fixed bugs, changes that will impact results etc.:
Description
This extension provides support for iOS mobile applications written in Swift built with Xcode.
In what situation should you install this extension?
If you have an iOS mobile application written in Swift and built with Xcode and you want to view the source code object types and their links with other objects, then you should install this extension.
How the CAST Delivery Manager Tool detects XCode projects
The Swift extension is dependent on the iOS extension, which includes a CAST Delivery Manager Tool (DMT) "plugin" that enables Xcode projects to be detected (see Xcode Discoverer). The DMT will search for the project.pbxproj (or a .pbxproj file) - when one is found, the contents are inspected and are used to determine the list of projects present in the root folder.
What are the differences with the CAST AIP extension for iOS?
The iOS extension is aimed at analyzing iOS mobile applications written in Objective-C (and to a lesser extent C and C++) and built with XCode. The Swift extension can do the same thing, however, it also supports source code written using the Swift technology.
Supported Languages
The following languages used to write iOS mobile applications are supported by this extension:
Technology | Supported | Notes |
---|---|---|
Objective-C | Supported via the dependent Objective-C extension. | |
C/C++ | ||
Swift | - |
Supported Versions
Version | Supported |
---|---|
3.2 - 4.2 |
Supported iOS and third-party frameworks
Please see the same section in the iOS extension for more information.
Function Point, Quality and Sizing support
- Function Points (transactions): a green tick indicates that OMG Function Point counting and Transaction Risk Index are supported
- Quality and Sizing: a green tick indicates that CAST can measure size and that a minimum set of Quality Rules exist
Function Points (transactions) | |
---|---|
Quality and Sizing |
CAST AIP compatibility
CAST AIP release | Supported |
---|---|
8.3.x | |
8.2.x | |
8.1.x | |
8.0.x | |
7.3.x |
Supported DBMS servers
This extension is compatible with the following DBMS servers:
DBMS | Supported |
---|---|
CSS | |
Oracle | |
Microsoft SQL Server |
Prerequisites
An installation of any compatible release of CAST AIP (see table above) |
Dependencies with other extensions
Some CAST extensions require the presence of other CAST extensions in order to function correctly. The Swift extension requires that the following other CAST extensions are also installed:
- iOS extension
- Web services linker service (internal technical extension)
Download and installation instructions
Please see:
The latest release status of this extension can be seen when downloading it from the CAST Extend server.
Packaging, delivering and analyzing your source code
Once the extension is installed, no further configuration changes are required before you can package your source code and run an analysis. The process of packaging, delivering and analyzing your source code is as follows:
Packaging and delivery
Using the CAST Delivery Manager Tool:
- create a new Version
- create a new Package for your Xcode application source code using the Files on your file system option and then click Next:
- Define the root folder of your Application source code:
- Check that the iOS Xcode project item under Type of projects to discover is ticked to ensure Xcode projects are discovered (if the option is not present, then the extension has not been installed successfully):
- Run the Package action: if your source code is a genuine Xcode project, then the CAST Delivery Manager Tool will discover the project(s) as shown below:
- Deliver the Version
Analyzing
Using the CAST Management Studio:
- Accept and deploy the Version in the CAST Management Studio.
- An Analysis Unit will have been automatically created in the Current Version tab for each Xcode project discovered by the CAST Delivery Manager Tool:
Note that in each Analysis Unit created for an Xcode project discovered by the CAST Delivery Manager Tool, the following two options should be set as shown below:
- No Analysis Units will be created automatically relating to the Swift source code - this is the expected behaviour, therefore you will need to create them manually. In the Current Version tab, add a new Analysis Unit specifically for your Swift source code, selecting the Add new Universal Analysis Unit option:
- Edit the new Analysis Unit and configure in the Source Settings tab:
- a name for the Analysis Unit
- ensure you tick the Swift option
- define the location of the deployed Swift source code (the CAST Management Studio will locate this automatically in the Deployment folder):
Analysis/snapshot generation
- Run a test analysis on the Analysis Units
- Make sure you have manually run the Import Assessment Models option.
- Generate a new snapshot.
Automatic exclusion of test and external dependency files from analysis
Analyzers are aimed at the study of the application source code. References and calls to external libraries are conveniently left out of the analysis, except for those that can be interpreted as elements taking part in a transaction, such as web service requests or database queries.
The Swift analyzer will skip files found inside the two standard locations of the two leading dependency managers: \Carthage\Checkouts and Pods. On the other hand, all files found inside a folder (or within sub-folders) with name ending "Tests" are considered as test files (consistent with XCODE conventions). This feature works upon detection of the project '.xcodeproj\' folder to assure the files belong to a SWIFT project. However, files with name ending as 'Tests.swift' are automatically skipped.
What results can you expect?
Once the analysis/snapshot generation has completed, you can view the results in the normal manner:
Objects
The following objects are displayed in CAST Enlighten:
Swift
Icon | Description | Description | |
---|---|---|---|
Swift Class | Swift DELETE http service | ||
Swift Enumeration | Swift GET http service | ||
Swift Function | Swift POST http service | ||
Swift Method | Swift PUT http service | ||
Swift Protocol | |||
Swift SourceCode | |||
Swift Structure | |||
Default Property Initializer |
Tip
If your application is supposed to be communicating with services, ensure you have GET, POST, PUT, DELETE Service objects created after the analysis.
C/C++
Icon | Description |
---|---|
Constructor | |
Class | |
Class Folder | |
Destructor | |
Directory | |
Enum | |
Enum Item | |
Free Function | |
Global Variable | |
Macro | |
Member Function | |
Member Variable | |
Namespace | |
Parameter | |
Root Directory | |
Source File | |
Template Class | |
Template Class Instance | |
Template Constructor | |
Template Constructor Instance | |
Template Free Function | |
Template Free Function Instance | |
Template Member Function | |
Template Member Function Instance | |
Template Parameter | |
Template Union | |
Template Union Instance | |
Typedef | |
Union | |
Additional File |
iOS & Objective-C
Icon | Description |
---|---|
Project | |
Workspace | |
Source File | |
Plist File | |
Story Board File | |
XIB File | |
UIApplication Delegate | |
UIApplication | |
Interface | |
Category | |
Protocol | |
Class Method | |
Method | |
Action | |
Get Resource Service | |
Post Resource Service | |
Put Resource Service | |
Delete Resource Service | |
Interface Variable | |
Outlet | |
Property | |
Property Getter | |
Property Setter | |
UI Button | |
UI Control | |
UI TextField |
Structural Rules
The following structural rules are provided:
You can also find a global list here:
https://technologies.castsoftware.com/rules?sec=t_1055000&ref=||
Web Services
Web service queries are supported for URLSession and the third-party library Alamofire. The same web service objects are used for both of them. For the former, as an example, the code of the form as below will create a Swift Delete http service object with url "http://localhost:8001/rest/todos/{}":
func deleteTodo(str: String) { var urlString = "http://localhost:8001/rest/todos/" + str; guard let url = URL(string: urlString) else { return } var deleteTask = URLRequest(url: (url as URL?)!, ...) deleteTask.httpMethod = "DELETE" URLSession.shared.dataTask(with: deleteTask) {(data, response, error) in if let jsonData = try? JSONSerialization.jsonObject(with: data!, options: []) { … }.resume() }
For Alamofire we support the request function. In the following example the web service call is represented by a Swift Get http service object
func getTodo(...) { guard let url = URL(string: "http://localhost:8001/rest/todos/") else {return} Alamofire.request(url, method: .get, ...) ... } }
The (call) links from Swift objects (functions, methods, ...) to Swift Web Service objects will be created by the analyzer as well. Similar to other analyzers, the responsible of further linking Services and Operations (possible inter-technology) is the dependency extension com.castsoftware.wbslinker. A picture of a simple call-graph including StoryBoard objects as entry points and Web Services as end points is shown in the following section.
Transactions for Function Points
In the example below we illustrate the results one can expect concerning transactions. The call graph starts from the StoryBoard widgets (eg Button and TextField) which are by default set as entry points. The StoryBoard defining these widgets is interpreted by the Objective-C Analyzer. After this; the Swift analyzer will then generate the links between these widgets and Swift objects, such as functions and methods. Eventually the call graph might reach different end points contributing to function point counting. In this example most of the StoryBoard widgets finish calling web services (these could potentially call web service operations inside the very same application so that the transaction would continue):
Click to enlarge
Known Limitations
- Some limitations come from the iOS extension, please refer to the iOS extension documentation.
- Some limitations come from the Objective-C analyzer, please refer to the Objective-C Analyzer documentation.
- Violations localized in Class Property Initializer objects are not visible in the Dashboard (to be included in forthcoming releases).
- Operator overloading and definition of custom operators is supported (at parsing level) but use of uncommon symbols may raise errors during the analysis.
Duplication of objects is avoided when preprocessing directives (#if, #endif) are used to specialize class, structure, prototype and Enum objects according to used frameworks. In the example below, a single Swift Structure object is generated, specifically, the first one appearing in the code:
#if os(iOS) || os(tvOS) import UIKit public struct TextInput<Base: UITextInput> { } #endif #if os(macOS) import Cocoa public struct TextInput<Base: NSTextInputClient> { } #endif