A Multifactor Comparative Assessment of Augmented Reality Frameworks in Diverse Computing Settings

Research and development on different augmented reality (AR) frameworks have come a long way when it comes to image tracking, object tracking, plane tracking and light estimation. However, there might be trade-offs and varying results obtained from different AR frameworks, depending on the use cases, and this is critical for consideration during immersive application development. Besides the current literature effort, this research proposes a multifactor comparative analysis of two core AR frameworks, which aims to analyze and evaluate ARKit and ARCore in diverse computing settings. This research developed a structural application which evaluated three major test parameters across ten devices spanning ARKit and ARCore. The first parameter relates to evaluating AR measurements using four different distance criteria. The second parameter evaluated resource utilization, relating to the central processing unit (CPU) and random access memory (RAM), while the last parameter evaluated plane detection based on light estimation. Findings conclude that ARKit is the preferable AR framework for AR measurement accuracy and reliability within the tested distance criteria. ARCore is the most optimized AR framework in terms of RAM utilization. Regarding plane detection based on light estimation, ARCore is the preferable choice under low lighting conditions, however, ARKit is the most suitable AR framework under adequate ambient lighting conditions. The findings of this research could guide future prototyping and immersive mobile application development within the context of the parameters used.


I. INTRODUCTION
The relevance of immersive technologies across different domains is evident in the different use cases that have emerged over the years, which includes marketing [1], education [2], agriculture [3], construction [4] and forensic science [5], to mention a few. It is important to note that the error margins and trade-offs that can be tolerated in the immersive applications developed across these domains may vary. This varying level of tolerance is due to the fact that the impact of an error in an immersive application could be more grave in certain domains than in others, for example, in construction [6] and forensic science [7] as opposed to The associate editor coordinating the review of this manuscript and approving it for publication was Andrea F. Abate .
advertising [1]. In advertising, the main objective is often to display the features of certain products or services and increase brand awareness [1], while in forensic science there is a higher level of sensitivity with respect to accuracy, and how the information presented to the court will inform the jury's decision as presented in Figure 1.
Accuracy and reliability are the core fundamentals in ensuring that credible crime scene measurement data has been captured. In crime scene data capturing, investigators must capture data without the risk of contaminating the scene [5]. Immersive technologies could enable a crime investigator to accurately capture measurement data without the risk of scene contamination. These technologies encompass virtual reality (VR), augmented reality (AR), mixed reality (MR) and extended reality (XR). AR and VR are the primary  technologies under immersive technologies, whilst MR and XR are a combination of AR and VR. VR in general offers three-dimensional (3D) computer generated environments, immersive, and multisensory experience [8], which relies on 3D, stereoscopic, head tracked displays, hand/body tracking and binaural sound as shown in Figure 2. VR can be broken up into the following categories [9]: • Non-immersive -A user maintains full awareness of the physical environment outside of the VR • Semi-immersive -More senses are immersed compared to non-immersive, but not all.
• Fully-immersive -stimulates all the user's senses. AR is a technology which can superimpose digital perceptual information in the real world [10]. AR can also be categorized into the following as described in Table 1. Figure 3. provides a schematic diagram example of fully imposed AR [15].
Prior implementations of AR/VR applications required bulky, computationally demanding and costly gear to function [16]. With further iterations in research and development, low-powered hand-held mobile devices (e.g smartphones) and headsets are able to run AR and VR applications [17]. The mobile operating system sector is primarily dominated by Android and iOS as shown in Figure 4. Android is an open-source mobile operating system utilized by a vast majority of smartphone companies, this operating system is developed, supported and owned by Google [18]. iOS is developed, supported and owned by Apple; it is not open source nor is the operating system utilized by any other company besides Apple [18]. Both Google and Apple developed  frameworks, which offer AR features [19], [20]. Google offers ARCore while Apple offers ARKit, both AR frameworks offer features which may achieve similar goals as shown in Table 2. However, the same level of accuracy may not necessarily always be achieved by both frameworks in certain applications. Table 2 provides a summary of the supported features in both ARCore and ARKit software development kit (SDK), which is applicable in this research. Features which are supported by either AR framework are indicated with a tick symbol, while those not supported are not filled (i.e blank). Furthermore, it is important to note that in certain domains that are seeking to integrate AR, accuracy deviations may be more severe, such as in forensic science where minor deviations in the information presented to a jury (see Figure 1) could wrongly inform a hypothesis about a crime scene, possibly rule off an entire case, or even lead to a death sentence.   In light of the above, it is instructive to understand how these frameworks may fare under different conditions and across varying mobile devices. This paper introduced a four-distance criteria measure across ten devices spanning ARKit and ARCore. Furthermore, it compared device system utilization, accuracy, runtimes for vertical and horizontal plane detections within a given parameter and the impacts of environmental light estimation on the outcome of the two frameworks. The aim is to explore accurate augmentation capabilities and provide guidance in diverse immersive systems development. There is limited research that has been conducted on comparing these two core AR frameworks especially with respect to AR accuracy measurements using different parameters across ten devices as considered in this research. This has motivated the need for this research, and could assist developers in understanding the potential tradeoffs at stake during prototyping and development of mobile immersive applications.
To the best of the researchers' knowledge, while there are research efforts on comparing these two frameworks [20], [22], [23], there is no study that has considered a multifactor analysis approach as proposed in the current research.
The remainder of this paper is structured as follows: Section II presents the related research and further justifies the novelty of our research. Section III presents the research methodology. Results are presented in Section III-B, while Section IV concludes the paper.

II. RELATED WORK
This section discusses some of the previous research efforts that relate to the comparison of ARKit and ARCore frameworks in diverse computing applications.
Nowacki et al. [22] scrutinize and compare ARCore and ARKit platforms for AR/VR applications. The aim was to evaluate the capabilities of ARKit and ARCore in determining which AR framework is applicable in speeding up prototyping and development of modern AR/VR applications. General performance in terms of time to load models, initialize run applications and cameras was measured. They also compared CPU loads and memory usage. Their work however only utilized obsolete devices and AR framework versions for the testing, thus rendering the results as outdated, compared to the current study. Their research also did not compare the accuracy measurements between ARKit and ARCore as done in this paper.
Chaudhry et al. [23] present an overview of ARFoundation and the ARCore SDK library. The aim of this research was to demonstrate the capabilities of ARCore regarding plane detection, light estimation and efficiency in terms of time taken to detect planes. Even though this research paper caters for plane detection, there is no mention as to how plane detection is affected under different lighting conditions. A point to also note is that this research paper only used a single mobile device in demonstrating these capabilities. However, in the current research ten different mobile devices, with five spanning each of the core frameworks, were utilized for testing the different parameters considered.
Cervenak et al. [20] describe the possibilities of indoor space mapping and user movement tracking using AR as well as incorporating accelerometers, gyroscopes and magnetometer sensors to acquire relative device positioning. The aim was to evaluate the possibilities of ARKit and ARCore with respect to movement in space, without using other navigation technologies. This study however based its findings on the use of ARKit 3 and ARKit 2 which are respectively three and four generations behind from the current version, which is ARKit 6.
Borduas et al. [19] present a study which provides insight and recommendations on which of the four mobile 3D scanning technologies (i.e., ARKit, ARCore, ScandyPro and the 3DSizeMe app) are reliable and sufficient for respiratory face mask customization. The aim is to compare the reliability of ARCore, ARKit, ScandyPro and the 3DSizeMe app using the Structure Sensor by Occipital. Findings show high errors with the ScandyPro scanning technology, suggesting that either a noisier scan or greater variability between scans is observed. ARKit, ARCore and 32SizeMe showed acceptable margins of error.
Oufqir et al. [24] present a study which evaluates the functionalities of two AR frameworks, ARKit and ARCore. This study evaluates how the two AR frameworks function, depending on the technology being used to detect and track objects, points, and features in a given scene. The aim of this study was twofold. First, it was to evaluate the capabilities of the two ARKit and ARCore libraries. Second, to evaluate their capabilities in the development of AR applications. This paper, however, did not evaluate the time taken to detect planes nor the comparison of augmentation under different lighting conditions as done in the current research.
Fabrício et al. [25] present a comparative analysis of existing AR frameworks that may allow for educational solutions. The objective of the study was to compare the characteristics of existing frameworks that may allow for the development of educational AR solutions to assist educators in their classrooms. The research focused on which AR framework would be the best at application development, however they never compared how well these AR frameworks fared in terms of accuracy. The versions of ARKit and ARCore used when conducting this research are also now Obsolete.
Carranza et al. [26] propose an AR plane detection application which aims to tag detected objects by means of labeling them and relaying said tagged information to visually impaired users. However, this study did not compare plane detection accuracy spanning multiple devices or how plane detections are handled under different lighting conditions as done in the current research.
While the aforementioned research efforts have conducted monumental research on comparing the two different AR frameworks (ARKit and ARCore), none of these research studies has considered the accuracy of AR measurements with four distance criteria, resource utilization as well as run-  time of plane detection and mapping under different ambient lighting conditions, using several different mobile devices as presented in this research. In the previous iteration of this work [27], we looked at the two dominating mobile operating systems and compared the AR frameworks they operate on. ARKit and ARCore were the two AR frameworks that were compared, but the comparison was only based on accuracy of AR measurements. Six mobile devices were used to conduct the prior study, in which five devices represented ARCore and one device was used to represent ARKit. The reason for this offset device selection is due to the fact that the ARKit device houses a LiDAR scanner and has the best configurations for dynamic ranging which all the other ARCore devices do not possess. Results from this study show that ARKit had the highest accuracy measurement average of 99.36% whereas ARCore had an accuracy average of 89.42%. In this new study, we added on more ARKit devices to balance out the ratio between ARKit and ARCore devices and also used multiple parameters to present a rigorous assessment of these AR frameworks. We added more test parameters such as acquiring AR measurements using four distance criteria across more devices, run time, system utilization checks, horizontal and vertical plane detection and mapping, so as to guide future immersive development.

III. DESIGN AND TESTING METHODOLOGY A. TEST SETUP
For this research, two mobile applications inspired by the AR Ruler application found on the google play store were developed, based on the latest versions of ARCore and ARKit, to determine plane detection accuracy and reliability in augmented reality solutions. Ten mobile devices were used in the testing, with five representing ARCore and the other five working with ARKit. The devices representing ARKit are the iPhones 8, Xr, 11, 11 Pro and the M1 iPad Pro 5th Gen. The devices representing ARCore are the following: Samsung A20, A32, S8, S10 and S20. Both applications were developed in Unity version 2022.1.22 using the latest ARKit and ARCore SDK plugins versions 5.0.2. AR Foundation version 5.0.2 was also utilized for the plane detection section. Visual studio 2021 was utilized for the backend C# coding, for the functionality such as the calculations for both applications. The application for the devices running ARCore was developed on a 6 core, 12 thread Ryzen 5 1600, 32GB of RAM running Windows 10 Pro version 22H2. The ARKit variant of the application was developed using a 6 core, 6 thread Intel ® Core i5, 8GB of RAM Apple mac Mini running mac OS Monterey. Xcode was also used to deploy and monitor all ARKit devices for RAM and CPU usage. Android studio was used to monitor all the ARCore running devices. The reason why we had to use two different applications (Xcode and Android studio) to monitor the different ARKit and ARCore devices is due to the fact that Xcode is only available for MacOS running machines. Figure 5 provides a compatibility illustration stating which devices are compatible with which software. Figure 8 depicts how AR frameworks work with mobile cameras in determining and detecting geometric planes using the parallax concept to determine depth. The parallax concept measures the angle of inclination between two lines by means of calculating the difference or displacement of an apparent object viewed along two unrelated lines of sight [28]. Figure 8 presents a single mobile device camera, a user must move the camera around to acquire a ''left eye'' and ''right eye'' view (i.e. different lines of sight) to record surfaces. Through the utilization of the mobile camera the AR frameworks are able to record and acquire the different inclination angles between  the two eye views through the parallax concept, thus enabling plane detection.

B. DATA COLLECTION AND EVALUATION METRIC 1) AR MEASUREMENTS
The nature of data required in the experiment are AR measurements. AR measurements acquired from these tests were compared to measurements captured with a control tape measure. For consistency, the test environment was controlled whereby multiple Ip20 40-watt Dali dimmer strips were used throughout the tests, ensuring adequate and consistent lighting for AR measurements.
A crime scene-related sample scenario was used, where the distance between two items within a crime scene represents either point A or B. The distance between these items were originally set to 100 cm for Figure 10 and 45cm for Figure 11 with a tape measure acting as the control. The same approach was used to set the ''75 cm'' and ''10 cm'' distance criteria. A crime scene use case was considered to see how practical AR measurements can assist at measuring crime scene evidence without the risk of contamination by means of physically touching the items. Figure 9 and 10 depict the practical use case of how the 100cm and 45cm criteria worked  when compared to the respective AR measurements observed (i.e., 99cm and 44 cm).
The accuracy of both AR frameworks were assessed based on how close they could get to the control criteria. Six test runs were conducted per device per measurement criteria as seen in Figure 9. Four measurement criteria were used, which are ''10cm'', ''45cm'', ''75cm'' and ''100cm'' at a distance of one meter (1m) and two meters (2m) proximities across all tests. The average score (D) of each device per measurement criteria after six test runs was then computed using Equation (1).D where N represents the total number of test runs that was conducted for each device (D) per distance criterion. Parameter X represents the measured distance between two points (A and B) per time per test for each D.

2) CPU AND RAM UTILIZATION
The next phase of this work required device processing and memory utilization readings whilst using the test application. Data acquired from these tests are then compared and calculated to determine the relative percentage change. End data calculations acquired from Equation (2), which computes the relative change, is used to help determine which AR framework is the most efficient and well optimized. Equation (2) was applied to both CPU and RAM utilization tests. These tests do not take the different operating systems into account, RAM management, CPU architectural builds nor the nanometer fabrication processes across these ten devices.
(X ) represents the relative change, j2 represents the final value, while j1 represents the initial value.

3) PLANE DETECTION VARIATION
The final phase of this research evaluated the different AR frameworks in terms of detecting horizontal and vertical planes in different lighting conditions as well as relative runtime in acquiring the relevant planes. Two lighting modes were used from the multiple Ip20 40-watt Dali dimmer strips. The first mode was where all the lights were set at the maximum of 40-Watts of lighting and the second was where the ambient lighting was kept at 14-Watts. For this test, the different AR frameworks had to map out the vertical and horizontal planes of the designated test area as shown in Figure 12.

IV. RESULT AND DISCUSSION
A. AR MEASUREMENTS Tables 5 and 6 show the raw data captured from the 75cm test criteria taken from 1 meter and 2 meters away respectively. The first row under the table headings represents the control tape measure. N/A has been designated for the control value since its value never changes. Figures 12 and 13 represent visual data extrapolated from the raw test data. The comparison between 10cm taken at 1 meter ( Figure 13) and at 2 meters ( Figure 14) depicts a trend whereby 60% of devices running either ARCore or ARKit seem to improve   in terms of accuracy at the 2-meter mark compared to the 1-meter mark. 30% of the devices retained the same accuracy across both measurement criteria, those being the Samsung S10, Samsung S20 and Samsung A32 as seen in Figure 13.
The comparison between 45cm taken at 1 meter ( Figure 15) and at 2 meters ( Figure 16) shows a different trend compared to the 10cm measurements. In this case, 50% of the devices improved at the 2-meter mark while 40% of the devices decreased in accuracy at the 2-meter mark and only 10% of the devices retained the same accuracy at both 1 meter and 2-meter mark as seen in Figure 15 and 16 The comparison between 75cm taken at 1-meter (Figure 17) and at 2 meters ( Figure 18) depicts a trend whereby  60% of devices running either ARCore or ARKit seem to improve in terms of accuracy the farther away they move from the targets being observed. 30% of devices in general worsened in accuracy the further away they got, and only 10% of the devices retained the same accuracy at both the 1-meter mark and 2-meter mark as seen in Figures 17 and 18.
However, the least accurate device in Figure 18 was the Samsung S20, which shows vast deviations of up to 81cm in the 75cm criteria. The most accurate device in Figure 17 was the iPad Pro. In Figure 18, the worst performing device was the iPhone 11 which had deviations of up to 83cm and the best performing device in Figure 18 was the iPad Pro.    The comparison between 100cm taken at 1 meter and at 2 meters depicts a great divide between devices that improved in accuracy at the 2-meter mark in comparison to devices that did not improve. 50% of devices running either ARCore or ARKit seemed to improve in terms of accuracy the farther away they were from the targets being measured. 50% of devices running under ARCore or ARKit did not improve and recorded a drop in accuracy at the 2-meter mark, compared to the 1-meter mark as seen in Figures 19 and 20.
The average accuracy percentage scores for the two AR frameworks are measured by applying Equation (1) and comparing them to the control value per criteria. The following can be noted, in Figure 13 ARCore scored an average   accuracy of 59.5% and ARKit scored an average accuracy of 92.67%. In Figure 14 ARCore scored 71.78% and ARKit scored 95.67%. In Figure 15 ARCore scored 99.38% and ARKit scored 99.11%. In Figure 16 ARCore scored 99.63% and ARKit scored 99.26. In Figure 17 ARCore scored 99.02% and ARKit scored 97.87%. In Figure 18 ARCore scored 99.24% and ARKit scored 99.33%. In Figure 19 ARCore scored 94.70% and ARKit scored 97.87%, while in Figure 20, ARCore scored 92.12% and ARKit scored 98.37%. Table 7 provides a summary and average score of how the two frameworks performed across all devices, spanning ARCore and ARKit in all given tests. These results were obtained by adding all the average percentages values obtained for each device across all tests, as shown in Figures 13, 13, 14, 15, 16, 17, 18 and 20. Then those total results were each divided by 5 to get the average accuracy score for each framework. The final result is shown in Table 7. Table 7 illustrates that ARKit proves to be far superior compared to ARCore regarding accuracy and reliability in AR related applications within the context of the criteria used in this   study. The performance ratio of ARKit to ARCore is 5:3 in the eight tests conducted. Figure 21 shows the average CPU usage per device, which draws the comparison between which AR framework is the most optimized and efficient for diverse computing AR applications. Each CPU check was conducted after a clean reboot with no background applications running, besides the operating system and the important service applications. The mobile devices were first checked 10 minutes after rebooting for idle CPU loads. Later, the devices were then evaluated 10 minutes into running the application for how much CPU load the developed applications were using. Xcode was used to verify this data for all the ARKit devices and CPU profiler was used to verify this data for Samsung devices running ARCore.

B. CPU AND RAM UTILIZATION
Applying Equation (2) to these results helped to determine the relative change amongst the devices. Figure 21 also depicts an expected performance trend between the devices with the weakest computational CPU consumption, and the strongest devices. The lower the CPU utilization the more capable the device is. The device with the best CPU utilization is M1 iPad Pro 5th Gen. The worst performing device in this lineup is the Samsung A20. Table 8 illustrates a performance summary of how the two frameworks performed across all devices, spanning ARCore and ARKit. ARKit showed a 14.84% lower CPU utilization   average compared to ARCore. ARKit in this test proves to be far superior compared to ARCore in terms of overall efficiency and optimization regarding CPU management in AR related applications within the context of the criteria used in this study. A point to note is that the CPUs utilized in all ARKit devices are greatly more powerful compared to most CPUs used in some of the ARCore devices, hence the large disparity in the overall CPU utilization. Figure 22 shows the RAM utilization comparison spanning the ten test devices used in this research. In this test, we noted that the iPhone 8 running ARKit seemed to be the worst optimized device, while the iPhone 11 Pro running ARKit seemed to be the most optimized for the test. On the other hand, the worst optimized device for ARCore was the Samsung S10 and the most optimized was the Samsung A20.  Table 9 presents the average comparison utilization between ARCore running devices and ARKit running devices. Based on Table 9, one can see that ARCore running devices on average used less RAM than ARKit running devices. Figure 23 shows the comparison between the time taken for planes to be detected under good lighting, which is 40-Watts of ambient lighting, and under bad lighting which is 14-Watts of ambient lighting. This test checks to see how the different AR frameworks function under different lighting conditions since both AR frameworks cater for light estimation and plane tracking. Table 10 depicts the summary of the average run time taken for planes to be detected within the test area, spanning ARKit and ARCore devices with two different lighting conditions. ARKit on average had a marginal lead over ARCore under 40-Watts of ambient lighting. In the tests conducted, we noted that ARCore running devices on average took 7.40 seconds to completely map out the test area. However, under the same lighting conditions, ARKit on average took 6.10 seconds to map out the same test area, which is significantly better than ARCore. Under 14-Watts of lighting, however, ARCore performs better than ARKit. We noted that the same test area took ARKit running devices on average 11.45 seconds to detect a plane, while it took ARCore running devices on average 11.35 seconds. The following relative percentage change can be noted from the two test cases conducted after applying Equation (2):

C. PLANE DETECTION VARIATION
• ARCore manages to handle lighting estimation and ranging better than ARKit.
• ARKit had a 90.54% relative percentage change under low light in comparison to good lighting.
• ARCore had a 51.08% relative percentage change under low light in comparison to good lighting.
Figures 24 and 25 present the results obtained from both ARKit and ARCore running devices under different lighting conditions while detecting planes in the designated test area. In Figure 24, A and B represent two ARCore devices under 14-Watts of ambient lighting, C and D represent two ARKit running devices. In the plane detection section, under bad lighting conditions, in some instances ARCore struggled to map out the test area correctly and at one stage had overlapping planes shown in A. In Figure 25, E and F represent two ARCore devices under 40-Watts of ambient lighting, G and H represent two ARKit running devices. In this test case scenario, both AR frameworks excellently mapped out the entire test area. Minor alignment issues were noted for both ARKit and ARCore running devices as seen in Figures 25(E and G).
An important point to note from all the test parameters conducted in this study is that, the chosen AR frameworks, ARKit and ARCore are not interchangeable between the different operating systems, Android and iOS. ARKit is only accessible to iOS running devices, irrespective of the different hardware components, a device running Android cannot run ARKit, irrespective of whether or not hardware limitations exist. The same can be said about ARCore, which is only offered for Android-running devices. The vendors, Google and Apple, do not cater for cross-platform functionality. Apple distinctively makes ARKit for only Apple devices [29] and Google makes ARCore for only Android running devices.
Tests conducted in this paper utilized two AR frameworks, ARKit and ARCore spanning different devices with different hardware configurations. This testing method ensured that there was no bias, hence the randomized device selection relevant to each framework. Figures 12-19 show that even a highend device can perform poorly in comparison to a relatively low-end device under certain constraints or parameters. The results show that the accuracy and reliability determination all boil down to how the AR framework functions in each test, and depending on the device. It is expected that this type of exploration will continue to evolve as there are continuous efforts by the vendors on improving these frameworks.

V. CONCLUSION
This work has provided a multifactor comparative evaluation of AR frameworks, ARKit and ARCore, aimed at diverse computing settings, using a crime scene related scenario as a use case. Three major evaluation parameters were considered, which are (i) AR measurements under four distance criteria; (ii) resource (CPU and RAM) utilization capacity; and (iii) plane detection under varying lighting conditions. The first evaluation involves eight test measurement criteria with six test runs per criteria to gauge the accuracy and reliability of the AR frameworks. The second evaluation involves comparing AR framework optimization and efficiency in diverse computing settings in terms of overall CPU and RAM utilization. The third evaluation comprises plane detection and mapping of a given test area under different ambient lighting conditions as well as the relative runtime.
Evaluation one consisted of ten devices split evenly between ARKit and ARCore, the four measurement criteria used are 10cm, 45cm, 75cm and 100cm at a distance of 1 meter and 2 meters' proximity across all tests. For the distance criteria, ARKit proved to be the most accurate and superior between the two frameworks by scoring an average accuracy of 97,52%, as opposed to the 89,42% scored by ARCore. M1 iPad Pro 5th Gen running ARKit was the most accurate and reliable device out of all the devices used based on seven out of the eight criteria used. A point to note is that the M1 iPad Pro 5th Gen houses a LiDAR scanner and has the best configurations for dynamic ranging, which all the other devices do not possess.
Evaluation two consisted of gauging the overall system (CPU and RAM) utilization between the two AR frameworks for efficiency and optimization. Results show that ARKit on average was the most efficient regarding CPU utilization. However, in the RAM management test, ARCore was the most optimized for this work.
Evaluation three consisted of gauging plane detection accuracy and light estimation under different lighting conditions. Results illustrated that ARKit was the preferable choice under 40-Watts of ambient lighting, however, under 14-Watts of ambient lighting ARCore was the preferable choice. Regarding plane detection accuracy across both tests, ARKit was the most accurate in mapping out planes for the designated test area. However, when it came to light estimation under the two different lighting conditions, ARCore was the most preferable AR framework in low lighting conditions, in comparison to ARKit. The results obtained have proven that both frameworks have their strengths within certain parameters, and further development is possible. The findings in this study could also guide future prototyping of immersive applications. It is expected that this type of exploration and analysis will continue to evolve based on future developments and technological advancement.