Unele dintre protocoalele prezentate anterior ca făcând parte din grupul protocoalelor de mijloc, de exemplu protocoalele pentru interoperabilitate create de IrDA: IrOBEX şi IrMC sunt considerate de unii specialişti ca fiind protocoale de nivel aplicaţie. Totuşi nu la acest tip de protocoale se referă grupul aplicaţiilor, ci la software-ul plasat deasupra stivei definite de SIG. Acest software este furnizat de firme specializate în dezvoltarea de software sau de către producătorii de dispozitive care doresc să acopere şi această latură, creând funcţii speciale pe care să le îndeplinească şi de pe urma cărora să beneficieze utilizatorii dspozitivelor Bluetooth. Acest lucru spune că fiind dată stiva de protocoale Bluetooth pentru un dispozitiv, este necesar să se scrie software-ul pentru aplicaţii care să “determine” acea stivă să îndeplinească anumite funcţii ca de exemplu: transfer de fişiere, conectare la reţea, etc. Grupul SIG nu a definit decât protocoalele de transport şi pe cele de mijloc, nu şi protocoale propriu-zise pentru aplicaţii. de asemenea nu a creat nici aşa-numitele API-uri (Aplication Programing Interfaces) – interfeţe pentru dezvoltarea de programe de aplicaţie. O importanţă deosebită o are realizarea în practică a scenariilor (profilurilor) Bluetooth. Şi pentru ca acest lucru să fie posibil trebuie scris software-ul necesar care să îndeplinească funcţiile respective imaginate prin scenariul de utilizare. Profilurile nu spun decât în ce fel să se construiască acele aplicaţii interoperabile, iar liniile propriu-zise de program nu se găsesc în specificaţie. Cei care se ocupă cu dezvoltarea de sotware pentru aplicaţii au suficiente libertăţi în ceea ce priveşte diferenţierea produselor fiecăruia prin adăugarea de trăsături particulare şi interfeţe pentru utilizare cât mai variate, fără să afecteze cumva cerinţele de interoperabilitate indispensabile ale acestor profiluri.
La acest nivel întâlnim două tipuri de aplicaţii posibile: unele deja existente la momentul apariţiei acestei tehnologii, să le spunem moştenite, proiectate pentru a folosi nivelurile de transport din stive ce corespund altor tehnologii, dar care pot fi desfăşurate şi prin linkuri Bluetooth, cu modificări minore sau chiar deloc ale software-ului respectiv. Acest lucru a dus aşa cum bine ştim la definirea nivelului special RFCOMM, capabil să preia fluxul informaţional din medii ca IrDA sau cabluri seriale. În plus aflăm că mai este necesar pentru unele platforme să existe încă un nivel între grupul protocoalelor middleware şi aplicaţiile propriu-zise, şi anume un nivel de adaptare a software-ului moştenit, la stiva Bluetooth (Bluetooth adaptation software). În a doua categorie de aplicaţii sunt cele special create pentru a opera în mediul Bluetooth. În acest caz este adesea avantajos să se dezvolte pentru aplicaţii aşa-numitele common services. Common services sunt considerate serviciile de securizare, de administrare a conexiunii, servicii SDP, etc. Ele pot fi realizate folosind limbaje de cod ca security manager, o consolă Bluetooth pentru management (poate chiar cu o interfaţă pentru utilizatori asociată, care să-i permită unui utilizator să selecteze dispozitivele şi serviciile dintr-o picoreţea cu care doreşte să interacţioneze), sau un program client-server obişnuit (iarăşi posibil cu o user interface pentru service searching şi browsing).
Ne putem totuşi întreba cum pot fi create aplicaţiile standard pentru cazurile de utilizare dacă specificaţia nu conţine şi API-uri. Răspunsul se găseşte în profiluri, care aşa cum ştim sunt create ca bază pentru utilizarea stivei de protocoale în desfăşurarea într-o manieră interoperabilă a anumitor “cazuri” de utilizare. Şi cum s-a dorit ca tehnologia de comunicaţie Bluetooth să fie folosită într-o multitudine de tipuri de dispozitive şi pe variate platforme, ar fi extrem de complicat să se imagineze şi creeze o singură interfaţă API standard potrivită pentru toate acestea. Atunci când o tehnologie este încorporată într-o platformă şi apare nevoia de a construi noi API-uri acestea sunt adesea mai bine construită de către experţii în acea platformă decât de către experţii în tehnologia respectivă. De aceea SIG a decis să nu creeze API-uri sub Linux, Windows, Symbian sau altele, ci profilurile conţinute în specificaţie să ofere funcţiile necesare acelora care vor să dezvolte API-uri pentru aplicaţii Bluetooth. Unele profiluri realizează totuşi acest lucru într-un mod direct. De exemplu profilul Service discovery descrie nişte modele posibile de programare şi defineşte primitivele service discovery care pot duce la API-uri. Dezvoltarea de aplicaţii nu se limitează însă la un software care să oglindească profilurile, ci odată cu diversificarea dispozitivelor, se lărgeşte orizontul pentru creatorii de aplicaţii. Nu s-a spus totul odată cu apariţia şi cunoaşterea primei versiuni a volumului de profiluri, altele noi vor fi fără îndoială dezvoltate şi vor apărea alte scenarii de utilizare pentru care se vor scrie aplicaţii, pe măsură ce se vor găsi noi utilizări ale tehnologiei Bluetooth.