iOS Export Settings provide a way to customize the export to your liking. We realize that every developer is different (we are developers after all), so the list is quite extensive! You'll find the list of settings with the explanation of every option below.
Specifies how the implementation files should be structured when the project is exported for iOS. The following options are available:
Group by Controller- Folders are created one per screen and named like the screen itself. All implementation files needed for that screen are put into the created folder.
Group by Type- Several folders of a predefined structure are created (for example, controllers, cells and so on). Implementation files are then put into those folders based on their type.
Flat- Every implementation file is exported into one single folder.
Keep in mind that the folder structure only affects implementation files. Other artifacts, such as fonts, assets, configuration files and so on are always put into their respective folders.
Use Machine Generated Files
When enabled, each class is generated twice - using
_Name patterns. While the content of the class exported in the
Name file doesn't change,
_Name is used for regeneration of the code when something changes. This way, you can write your customization code into one file, not worrying that your work would be lost when something in Supernova changes.
Machine-generated file structure
Specifies how the machine files (
_Name) should be generated. The following options are available:
Separate Folder- Prefixed classes are all generated into one single folder
Attached Folder- A new folder is created under the specific structure for each controller
Keep Together- The machine file will always be generated next to its static counterpart
Keeping code in sync
This is the preferred option to keep your code in sync with Supernova.
Scope of exposed interface builder outlets generated by Supernova. Available options are
Reference type of exposed interface builder outlets generated by Supernova. Available options are
Indentation character used for proper spacing of generated code. Available options are
Indent Character Count
The number of indentation characters per one indent level - for example, if there is a method inside a class, the method will be indented with 1*n indent characters, but any code inside it will be indented with at last 2*n indent characters (e.g. - 4, 8 spaces or 1, 2 tabs).
Specifies how the brace behavior works. The following options are available:
Same Line- Opening braces start on the same line, preceded by one space.
New Line- Opening braces start on the new line, following indentation rules set above
When enabled, Supernova generates comments for the code where appropriate. The comments are not intrusive and are usually only placed where they really have some value.
Generate Beginner Comments
When enabled, Supernova generates additional comments to explain what is done. This can result in a large number of comments but is great for understanding of the code.
Spacing (before / after) (code structure)
The number of empty lines before every specific code structure.
Empty lines at the end of the file
The number of empty lines after the last line of code in the file. Some IDEs don't allow for extraneous padding at the end of the edited file so this option is a good workaround for it.
Defines the section separator between each logical section of the code (properties, methods and so on). By default, separators are generated using default pragma marks with a bit of visual separation on top:
// --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- // MARK: - _sectionname_
You can use the
_sectionname_ tag to identify which section it is (will be replaced when exporting).
Defines the header block that is added to the beginning of every generated code file. By default, the code is the default one used by Apple in their own projects:
// // _filename_ // _projectname_ // // Created by _authorname_. // Copyright © 2019 _companyname_. All rights reserved. //
You can use
_companyname_ tags to further enhance your headers with additional dynamic information (will be replaced when exporting).
Class name suffixes
When exporting, Supernova uses a smart naming engine to keep everything as unified as possible. You can select how the replacement of class names should look like - for example, if your screen is named
Onboarding Flow, the output name will be by default exported as
OnboardingFlowViewController. However with these settings, you can change it so the output will look like
OnboardingFlow, or even something completely custom like
Overriding class names
You can override the exported screen class name completely, in which case those rules are not applied - select the screen you'd like to rename and write your desired name in the
screen classproperty in the code section on the right panel.
Property name suffixes
When exporting, Supernova uses a smart naming engine to keep everything as unified as possible. you can select how the replacement of property names should look like - for example, if your component is named
Header, the output name will be by default exported as
headerView. However with these settings, you can change it so the output will look like "header" or even something custom like
Overriding property names
You can override the exported property name completely, in which case those rules are not applied - select the component you'd like to rename and write your desired name in the
property nameproperty in the code section on the right panel.
Updated almost 3 years ago