SUGISAKAMASANORI

Journal of Robotics, Networking and Artificial
Life Vol. 10(4); March (2024), pp. 336–341
ISSN (Online): 2352-6386; ISSN (Print): 2405-9021
https://alife-robotics.org/jrnal.html

Research Article

RAGESS: A Tool for Real-time Automatic Generation of
SwiftDiagram to Support iOS Application Development
Haruki Onaga1, Tetsuro Katayama1, Yoshihiro Kita2, Hisaaki Yamaba1, Kentaro Aburada1, Naonobu Okazaki1
Department of Computer Science and Systems Engineering, Faculty of Engineering, University of Miyazaki, 1-1 Gakuen-kibanadai nishi, Miyazaki, 889-2192
Japan
2
Department of Information Security, Faculty of Information Systems, Siebold Campus, University of Nagasak, 1-1-1 Manabino, Nagayo-cho, Nishi-Sonogi-gun,Nagasaki, 851-2195 Japan

1

ARTICLE INFO
Article History
Received 24 November 2023
Accepted 19 June 2024
Keywords
Software visualization
Mobile application
iOS
Swift

ABSTRACT

It is difficult for mobile application developers to understand the structure of large and complex
mobile applications. To support iOS application development, we proposed SwiftDiagram: avisualization of the static structure of Swift source code, and demonstrated its usefulness. To
further support them, this paper has implemented RAGESS(Real-time Automatic Generation of
SwiftDiagram System), which is a software visualization tool. RAGESS performs static analysis
on Swift source code and automatically generates the corresponding SwiftDiagram whenever thetarget project build succeeds.
© 2022 The Author. Published by Sugisaka Masanori at ALife Robotics Corporation Ltd.
This is an open access article distributed under the CC BY-NC 4.0 license(http://creativecommons.org/licenses/by-nc/4.0/).

intensive and error-prone. Therefore, to further support
iOS application developers, we develop a prototype tool
called RAGESS (Real-time Automatic Generation of
SwiftDiagram System). RAGESS monitors thedeveloper-selected project. When it detects that the
project’s build is successful, it performs static analysis on
the source code and generates the corresponding
SwiftDiagram. RAGESS immediately displays thegenerated SwiftDiagram, categorized into protocols,
structures, classes, and enumerations.

1. Introduction
The market for mobile applications targeting
smartphones and tablets is expanding every year [1]. As
a result, mobile applications are becoming larger andmore complex, driven by the demand for continuous
releases in short cycles [2]. In such development, thefollowing problems exist for mobile application
developers.
••

Difficult to understand the overall structure of theapplication by reading the source code
Difficult to keep track of where changes made to
the source code may have an impact within the
project

2. SwiftDiagram
SwiftDiagram is a diagram that supports the design andmaintenance of iOS applications for source code written
in Swift. To achieve this, SwiftDiagram visualizes thefollowing:

We proposed SwiftDiagram to solve these problems
with a software visualization approach. SwiftDiagram isa diagram that visualizes the static structure and impact
scope of source code written in Swift [3]. Swift is a
programming language used to develop iOS applications.
However, manually drawing a SwiftDiagram is labor-••

The static structural composition of types
The impact range resulting from modifications
made to a type or its constituent elements

Corresponding author E-mail: onaga@earth.cs.miyazaki-u.ac.jp, kat@cs.miyazaki-u.ac.jp, kita@sun.ac.jp, yamaba@cs.miyazaki-u.ac.jp,
aburada@cs.miyazaki-u.ac.jp, oka@cs.miyazaki-u.ac.jp336

Fig.1 Component of SwiftDiagram

Fig.2 An appearance of RAGESS’s user interface, with descriptions of its main components

3. Prototype of RAGESSSwiftDiagram is constructed using four different kindsof components and a single type of arrow, which are
explained the below. The components of SwiftDiagram
are shown in Fig. 1.
•
•
•
•
•

We implement RAGESS as an application running on
macOS using Swift and SwiftUI [4]. To use functions of
RAGESS, the mobile application developer selects the
project directory and the build file they want tovisualize .111with SwiftDiagram using the standard
macOS file selection dialog.

Header Component
Shows a type identifier, such as access level, type
categories, and name
Details Component
Shows the components of a type, such as variables,
functions, inheritance relationships, and so on
Extension Component
Shows type extensions defined in extension code
blocksNest Component
Shows types that are declared within the scope ofanother type
Impact Range(arrow)Shows that changes to the type at root of the arrow
may impact the component of the other type ofdestination of the arrow

3.1. Appearance of RAGESS
Fig. 2 shows the appearance of RAGESS after it has
generated and displayed SwiftDiagram. The userinterface of RAGESS consists of the following
components:
•
•

337

An area displaying the generated SwiftDiagram
An area displaying the path of selected project andthe last change date and timeFig.3 An example representing the correspondence between the SwiftDiagram and the Swift source code
•
•
•
•
•

the user can adjust the opacity of the arrows by using slidebar. Clicking the “Show All Dependencies” button
reverts the impact range and arrow opacity to their initialstate, displaying all the arrows representing the impact
range for the entire project.

A slide bar to control the magnification level ofthe SwiftDiagram
A slide bar to control the opacity of the arrows
A button to make all arrows visible
A button to select a directory of the target project
A button to select a build file of the target project

4. Application Example

3.2. Features of RAGESSAs one of application examples, we verify that thefeatures of RAGESS works correctly for Swift sourcecode that defines multiple types. Fig. 3 shows thecorrespondence between the SwiftDiagram generated by
RAGESS and the Swift source code in the example. Fig.
2 shows the screen of RAGESS when it monitors thebuild file of the project containing the Swift source codein the example and detects a successful build.
Comparing the SwiftDiagram and Swift source code in
Fig. 3, we can see that the structure name and propertiesof StructA in the SwiftDiagram correspond to those in the
Swift source code. Likewise, for StructC, the structure
name, properties, and dependencies based on protocol
conformance in the SwiftDiagram align with theircounterparts in the Swift source code.
Additionally, in the SwiftDiagram, ProtocolA,
SuperClass, and StructB have arrows pointing to thecomponents of other types that could potentially be
impacted by modifications made to these types.
Furthermore, as another application example, we
verify that the RAGESS functionality works correctly fora simplified Swift source code that represents a portion of
itself. Fig. 4 shows the simplified Swift source code forthe data objects in RAGESS that hold structures andvariables. Fig. 5 shows the screen after RAGESS
monitors the build file of the sample project containing

RAGESS has two primary features, which are as follows:••

Real-time automatic generation and display of the
SwiftDiagram corresponding to the latest sourcecode of the target project whenever its build
succeeds
Display of the impact range of a single type

RAGESS keeps track of the build file of the target
project. Whenever RAGESS notices a change in the build
file, it conducts a static analysis of the project’s Swiftsource code and automatically generate thecorresponding SwiftDiagram. This not only eliminates
the need for developers to manually update the
SwiftDiagram but also guarantees that the generated
SwiftDiagram does not contain syntax errors. The static
analysis of Swift source code is carried out using
SwiftSyntax [5], an open-source tool made available byApple. The developer can adjust the magnification levelof the displayed SwiftDiagram by operating the slide bar.
Representing the entire structure of the target projectin SwiftDiagram might result in complex arrows
depicting the impact range, potentially hindering thedeveloper’s understanding of the structure. When thedeveloper clicks on a header component of the
SwiftDiagram generated by RAGESS, it narrows down
the display to only the arrows representing the impact
range of changes made to that specific type. Furthermore,338

Moreover, the source code in Fig. 4 declares four
protocols, two structures, and two enumerations. Amongthe protocols, Holder, AccessLevelRepresentable, andNameable are conformed to by both structures. In the
SwiftDiagram in Fig. 5, arrows are connected from eachof these three protocols to the “Conform” parts of the two
structures. The TypeRepresentable protocol is only
conformed to by the VariableHolder structure, andcorrespondingly, in the SwiftDiagram in Fig. 5, an arrowis connected only to the “Conform” part of
VariableHolder. Furthermore, the StructHolder structure
has a property with an array of VariableHolder structures
as its type. In the SwiftDiagram in Fig. 5, an arrow isconnected from the VariableHolder structure to theproperty of the StructHolder structure. Similarly, the twoenumerations also have arrows connecting to theproperties for which they serve as types.
Therefore, it is clear that RAGESS can staticallyanalyze Swift source code and generate thecorresponding SwiftDiagram.
5. Related work
Another tool for visualizing Swift source code is Emerge[6]. Emerge is a web-based tool that provides
visualizations of the codebase and dependencies forvarious programming languages, such as Swift,
JavaScript, and Python. By visualizing the source code asa graph structure consisting of nodes and edges, it enables
visual exploration and analysis.
Emerge examines source files in the specified
directory that are written in a developer-defined language
and produces file for rendering graphs in a web browser.
By loading these files in a web browser, developers cananalyze the dependencies. However, any modifications
made to the source code after the analysis are notreflected in the graph displayed in the web browser.
Moreover, because Emerge represents types and files asnodes, it is unable to analyze the dependencies at the levelof type components. On the other hand, RAGESS
automatically generates SwiftDiagram every time thetarget project’s build is successful. Additionally, since
the arrows are linked to type components like properties
and methods, developers can gain a more comprehensive
understanding of the dependencies.
And another visualization tool targeting Swift is
Swiftcity [7], [8]. This tool adapts the city metaphor to
Swift’s unique features like type extensions andstructures, visualizing the source code as cities andbuildings. The height of each building corresponds to thenumber of lines of code (LOC) in a type, while the widthand depth represent the number of methods.
However, Swiftcity doesn’t visualize components suchas properties and enumeration cases, or dependencies likefunction calls and protocol conformance. On the other
hand, RAGESS can represent the scale of a type throughthe combined height of the SwiftDiagram components
and visualize type components beyond just methods, aswell as the scope affected by changes.

Fig.4 RAGESS source code with simplified data objects
holding structures and variables
the Swift source code from Fig. 4 and detects a successfulbuild.
Comparing the source code in Fig. 4 with theSwiftDiagram in Fig. 5, the names of the types, variables,and enumeration cases match respectively. In the source
code, the access levels for types and variables are omitted,
and the SwiftDiagram generated by RAGESS correctly
applies the default access level “internal”.
339

Fig.5 Screen after applying RAGESS to the source code in Fig.4
Therefore, RAGESS can visualize the structure of a
project in greater detail. Moreover, by updating theSwiftDiagram in real-time every time the project build
succeeds, RAGESS reduces the effort required bydevelopers to modify the artifacts.
Therefore, RAGESS provides a more detailed
visualization of the target project structure than the othertwo tools for visualizing Swift source code. Moreover, it
automatically updates the SwiftDiagram after eachsuccessful build of the target project, reducing the amountof time the developer has to modify the artifacts.

Additionally, we compared RAGESS with other toolsthat apply software visualization approaches to Swiftsource code. The results showed that RAGESS canvisualize that structure of a target project in more detailand in real-time compared to the other tools.
Consequently, RAGESS has the potential to support
iOS application development using the Swiftprogramming language.
Future works include the following:•

6. Conclusion••

In this paper, we have developed a prototype of RAGESS,a software visualization tool aimed at supporting iOS
application development. RAGESS performs static
analysis on source code written in the Swift programming
language and generates and displays a SwiftDiagram. By
monitoring the target project and detecting successfulbuilds,RAGESS
automatically
updatesthe
SwiftDiagram.
We applied RAGESS to two different examples of
Swift source code and confirmed that it can generate
SwiftDiagram corresponding to each example.

Evaluation of the usefulness of RAGESS throughsubject experiments involving experienced iOS
application developers
Implementation of search feature
Visualization at different levels of abstraction

References
1.

2.

340

Ministry of Internal Affairs and Communications,Japan, Information and Communications in Japan
WHITE PAPER 2022,
https://www.soumu.go.jp/johotsusintokei/whitepaper/eng/WP2022/2022-index.html
Ronald Jabangwe, Henry Edison, Anh Nguyen Duc.
Software engineering process models for mobile app
development: A systematic literature review. The

3.
4.
5.
6.
7.

8.

Journal of Systems & Software. 2018, 145, pp.98111.
Apple, Swift, https://developer.apple.com/document
ation/swift (Accessed 2024-6-13)
Apple, SwiftUI, https://developer.apple.com/documentation/swiftui (Accessed 2024-6-13)
GitHub, swift-syntax, https://github.com/apple/swiftsyntax (Accessed 2023-12-14)
GitHub, emerge, https://github.com/glato/emerge(Accessed 2023-12-14)
Rafael Nunes, Marcel Rebouc a̧ s, Francisco SoaresNeto, Fernando Castor. Poster: Visualizing Swift
Projects as Cities. IEEE/ACM 39th International
Conference on Software Engineering Companion.
2017, pp. 368-370.
Swiftcity, https://swiftcity.github.io/swiftcity-app/(Accessed 2023-12-14)

Dr. Hisaaki Yamaba
He received the B.S. and M.S. degrees inchemical engineering from the Tokyo
Institute of Technology, Japan, in 1988
and 1990, respectively, and the Ph D.
degree in systems engineering from the
University of Miyazaki, Japan in 2011. He
is currently an Assistant Professor with
the Faculty of Engineering, University ofMiyazaki, Japan. His research interests include network
security and user authentication. He is a member of SICE
and SCEJ.
Dr. Kentaro Aburada
He received the B.S., M.S, and Ph.D.
degrees in computer science and systemengineering from the University ofMiyazaki, Japan, in 2003, 2005, and 2009,
respectively. He is currently an Associate
Professor with the Faculty of Engineering,
University of Miyazaki, Japan. His
research interests include computer networks and security.
He is a member of IPSJ and IEICE.

Authors Introduction
Mr. Haruki Onaga

He received the Bachelor's degree inengineering (computer science andsystems
engineering)fromthe
University of Miyazaki, Japan in 2023.
He is currently a Master's student in
Graduate School of Engineering at the
University of Miyazaki, Japan. His
research interests include softwaredevelopment support through software

Dr. Naonobu Okazaki
He received his B.S, M.S., and Ph.D.
degreesinelectricalandcommunication engineering fromTohoku University, Japan, in 1986,
1988 and 1992, respectively. He joined
the Information Technology Researchand Development Center, Mitsubishi
Electric Corporation in 1991. He iscurrently a Professor with the Faculty ofEngineering, University of Miyazaki
since 2002. His research interests include mobile networkand network security. He is a member of IPSJ, IEICE andIEEE.

Dr. Tetsuro Katayama

He received a Ph.D. degree inengineering from Kyushu University,
Fukuoka, Japan, in 1996. From 1996 to
2000, he has been a Research Associate at
the Graduate School of Information
Science, Nara Institute of Science andTechnology, Japan. Since 2000 he has
been an Associate Professor at theFaculty of Engineering, Miyazaki University, Japan. He iscurrently a Professor with the Faculty of Engineering,
University of Miyazaki, Japan. His research interests
include software testing and quality. He is a member of the
IPSJ, IEICE, and JSSST.
Dr. Yoshihiro Kita

He received a Ph.D. degree in systems
engineering from the University ofMiyazaki, Japan, in 2011.
He iscurrently an Associate Professor with theFaculty of Information Systems,
University of Nagasaki, Japan. His
research interests include software
testing and biometrics authentication.

341