Hearing Screening App

Arebr15 Arian Ebrahimi

Moole15 Morten Abrahamsen Olesen

BitBucket – https://bitbucket.org/moole-arebr/ioshearingscreeningapp/src/master/

Demo – https://youtu.be/X5o4ZnS5bZs (The audio is switching from left to right, but its hard to hear in the video)


Chemotherapy often leaves cancer patients with worse hearing, and with everything already going on in their lives this app will make it easy for them to make sure they don’t risk losing their hearing. No waiting rooms or high costs, all that is needed is a phone and some earbuds or headphones. To solve this problem an android app has been developed, but in order to make this solution available to more people an equivalent is needed on the iOS App store.

Basic idea

By varying frequency and amplitude, then asking if the user can hear the tone, we can test the users hearing and find where the user has deficits and track the hearing over time.

Why is this subject important?

Cancer patients have enough to worry about, making the hearing test as easy as it can be helps alleviate the stress which something like an extra doctor’s visit a month might add to such a patient’s life.

Common platform

  • One up two down
    • One up two down simply means that every time the user succeeds they move ahead one and every time they fail they move back two, in our case that is instantiated in the amplitude getting 2 louder when you fail and one quieter when you succeed

Problem statement

Make an app that can test the users hearing when it comes to both frequency and amplitude, making sure they aren’t losing frequencies or sensitivity in the their hearing over time.

Introduction 2

Basic idea 2

Why is this subject important? 2

Common platform 2

Problem statement 2

Methods & materials 3

Idea 3

Prototyping 4

Development 4

Requirements 4

Implementation 5

Frameworks 5

AudioKit 5

Frequency tester 5

The hearing test 6

Results 7

Conceptual design 7

Prototyping on paper 8

Prototyping in Xcode 9

Discussion 13

Overall 13

In the hands of users 13

How we would continue to improve 13

Conclusion 13

Perspective 14

References 14

Methods & materials


The original idea for the app was developed in Android and then suggested as a for this course. Given that the project had been developed on another platform already a great deal of inspiration was taken from that product, and several meetings were arranged and had to hone in development.


Early prototypes were developed using POP (prototyping on paper) this allowed for quick and dirty prototyping so that we layout and interactions of each page could be determined with minimal time waste.

Later on views for the app were made in Xcode, and rudimental hooked up, this made it fast to move things around and get a real feel for the app.


Much of the project was developed while pair programming, meaning alternating members coding while the other watches and gives input.

Some of this project was also developed separately by a group member and then presented and introduced to the other.


The basics of the app is a hearing test, which also is the main requirement for the app.

  • The ability to conduct a hearing test
      1. The purpose of the app is to be able to conduct a hearing test of a cancer patient, after chemotherapy.
  • The audio should be able to switch audio channel from left to right or vice versa
      1. The purpose of switching audio channel is for an isolated test of each ear, before continuing.
  • The ability to vary frequency and amplitude
      1. Its required to change the frequency and amplitude, to be able to utilise the One Up Two Down correctly
  • The hearing test utilises One Up Two Down
    1. The One Up Two Down method is used to test the patient’s hearing, by increasing the volume if they fail the first test, and decreasing the volume if they pass.




When making an app which should be able to playback audio at different frequencies and amplitude, AudioKit is definitely the right choice.

For this project, AudioKit is an essential part of the code, as the ‘Hearing Screening App’s’ basic functions requires AudioKit.

Frequency tester

class ThirdViewController: UIViewController {
  var oscillator = AKOscillator()
  var freq = 1000


Starting off by initializing the oscillator and setting a default frequency

  @IBAction func toggleSound(_ sender: UIButton) {
      if oscillator.isStarted {
      } else {
      try? AudioKit.start()

Hereafter a check to see if the oscillator is already started and the stopping it, if it is. If its not started then we start it. The reason to why we do this, is so we can use the button for both starting and stopping the oscillator.

  @IBAction func raiseFrequency(_ sender: UIButton) {
      freq += 100
      oscillator.frequency = Double(freq)
      freqLabel.text = String(freq)

When we want to change the frequency we simply press the + or – button, which then raises or lowers the frequency by a 100 each time.

The hearing test

var oscillator = AKOscillator()

let frequencies : [Double] = [250, 500, 1000, 2000, 3000, 4000, 6000, 8000]
let amplitudes : [Double] = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9]
var frequencyPlaying = 0
var amplitudePlaying = 4
var successes = 0
var panner = AKPanner(oscillator)

class OneUpTwoDownTest {


For the hearing test, we created two arrays, one for frequencies and one for amplitudes.

A panner is also created to control which ear the audio is playing in first.


Conceptual design

To get an idea of what needed to be developed meetings were held with a developer of the android version, here notes were made of the layout and functionality of each page, and any guidance that could be gleaned from the development of the android version, to help with the iOS rendition.

Early on it became clear that there were some limitations to the android version which were easily mitigated in the iOS version, the most important being that the android version produced sound by having recordings of each tone the developers felt was needed. In iOS producing sounds at any frequency quickly becomes trivial when using AudioKit, here a tone of any frequency or amplitude can be produced and played programmatically.

Image 1 – Android Menu

Image 2 – Calibration

Having gotten a better understanding of the android version and the translation to iOS, the group became formalizing the work that needed doing. Here the group created a use case diagram detailing how pages would interact and giving a broad sense of what the apps functionality and layout would be.

Prototyping on paper

After having met with the developer of the Android version of the hearing app, several iterations of paper prototypes were developed and introduced to fellow students. This resulted in the final design, which is seen below, as the students felt that the design were good enough and captured what is needed, to use and understand the app. The final design is close to the android version, but with a more clean look which makes it easier to look at, the POP can be seen below and the app version further down.

This prototype shows the initial menu with a simple center aligned row of buttons, each leading two another view. From top to bottom the order was decided to be: tutorial, start test, calibration, frequency test. These were translations from the original android app, but reworked to fit this prototype and the restraints of the project.

The second view in the prototype is a simple representation of the hearing test in action, all that is visible is a bit of text asking if the user heard the sound, and two buttons to record their answer.

The last view is of a frequency test, in which the user can adjust the pitch of the sound they are hearing. This was not present in the original android app, but it was felt this would suit the iOS version well, because of how easily sounds can be manipulated in iOS, as compared to android. The view contains two buttons which adjust the frequency, one up and the other down, and a single button to play the sound, lastly a small label shows the frequency that has been set.

Prototyping in Xcode

Image 3 shows the second iteration and last iteration of the design of the menu. Within this scene there are 5 buttons, which is grouped and aligned to center. Each button have a segue which leads to a new view.
The second image (Image 4) shows the basic design of the “How To” view, where you will get the basic information on how to start the test and how it works.

Image 3 – iOS Menu
Image 4 – How To
Image 5 – Frequency Tester
Image 6 – Hearing test

The view of image 5 is a clean view with 3 buttons and 2 labels.

  • Play sound
        1. This button plays a specific frequency, which can be controlled by the “+ / -” buttons in the top.
      1. This button also works as a stop button, to when you want to stop playing the given frequency.
  • Frequency buttons
    1. The plus and minus buttons controls the frequency at which is played when pressing the “Play sound” button. Each press will either increase/decrease the frequency by 100 each time.
Image 7 & 8 – Volume test & Calibration

Image 7 is the volume test view, which has 2 text areas to insert values to played, this will then be put into a schema to see if the values corresponds to the true noise level.

The next view is used to calibrate the speakers/headphones to play the sounds at correct levels based on the input of the value recorded by an artificial ear/microphone.

The final product

The final product delivers on the main functionalities of the android version, it has a hearing test, that follows the same patterns and the ability to play specified frequencies, that the user can adjust.

The hearing test will play audio in one ear at a time as the original and then follow the One Up Two Down for increasing the frequency and amplitude of the audio based on the results.

Furthermore all the views for future iterations of the app have been created and finished, it’s only the implementation of their features that need to be developed. Meaning future development is already planned and prepared.



The main functionality of the app is done, meaning we got the app is able to handle a real hearing test, with the same methodology as the android version. We would have liked to complete our calibration functionality so that the exact dB’s of our hearing test could be adaptive to the hardware playing the sounds, but with the time we had we were not able to get to it.

In the hands of users

Our group evaluations were very well received, and every time we talked with users (other students) we received positive feedback on both the idea and the functionality. Although our one up two down methodology had not been implemented for the last presentation users responded positively to the ability of our ap to adjust both frequency and amplitude dynamically and were able to navigate our UI without needing an introduction.

How we would continue to improve

There are still functionalities that are essential to making the application viable in a medical environment which we have not had resources to tackle, the most glaring of these being the calibration of amplitude in order to give perfect control over the hearing test accuracy.

Give more time to advance the project we would like to apply some of the strengths that iOS has in the Project, one of the major ones being the complete control over frequencies, which the original android app lacked. The Android version makes use of a few sound files with a consistent tone at a set frequency, menacing that it could play those times and only those. With AudioKit we can generate any tone we wish to.

Though it was never part of our scope, creating some storage functionality for the iOS app would be an important addition, this would let the user or their doctor compare their current results with previous ones easily.


Our application can provide a one up two down hearing test to users, and can be adjusted manually to produce any tones relevant, but lacks the ability to adjust its amplitude to the equipment it is being used on.

We have integrated AudioKit and are able to derive from it any tone we wish and we can adjust it to find the very edges of anyone’s hearing, on top of that we can generate a standard hearing test which runs through a preset of frequencies ensuring a quick check of the users hearing


The next implementation would be the calibration and incorporating its data in the test would complete the test and make it exactly as it is in the android version.

Additionally making the app store data would make reviewing the past easier.


AudioKit – https://audiokit.io/

Android Version Hearing Screening App (Chris Bang) – https://drive.google.com/open?id=10IOnmeO6pcZGsdTi_7YB9EsMLXrHLOY7

Leave a Reply